Tag: Leadership

From Tactical Requirements Manager to Creative Leader of Innovative Change

Written by Kathleen B. Hass, PMP on March 5, 2012. Posted in Articles.

The Adaptive Business Analyst – As Complexity Increases, the BA Adapts

The world, she is a’changin’. The Internet has made everyone on the globe hyper-connected and has transformed virtually all industries: publishing, broadcasting, communications, and manufacturing. Did you know that just a few short years ago:

Facebook	Didn’t exist
Twitter	Was a sound
LinkedIn	Was a prison
A Cloud	Was in the sky
An Application	Was something you used to get into college
4G	Was a parking space
Skype	Was a typo[1]

Fast forward to now. Traditional work has been commoditized. Anyone with an idea and a little moxie can use their laptop to set in motion a virtual new entity. You can go to:

Taiwan	For product design
Alibaba in China	For low-cost manufacturing
Amazon.com	For delivery and fulfillment
Craigs List	To do your accounting
Freelance.com	To do your logo[2]

If this isn’t bad enough, the heart and soul of middle class jobs are disappearing in the U.S. Consider this: When Apple began manufacturing the iPhone, the company estimated that it would take nine months to find 8,700 qualified industrial engineers in the U.S. to oversee and guide the 200,000 assembly-line workers eventually involved in manufacturing iPhones. In China, it took 15 days.[3] Result: we lost 200,000 iPhone manufacturing jobs.

Many believe that these and many other traditional jobs are not coming back to the U.S. So, what are the jobs of the future? We probably don’t even know what to call them, but they will definitely require creativity, innovation, invention, and lots of complexity. Even today, many companies in Silicon Valley do quarterly reviews of their key project leaders because they can’t wait to find out they have a poor BA or PM. Many U.S. companies report they can’t find the employees they need. American businesses also report that U.S. workers that are available are too expensive and too poorly educated as compared to workers in India, China, South Korea and many other countries.

What does all this Mean to the Business Analyst?

Employers are looking for critical thinking and an ability to adapt, invent, and reinvent; collaborate, create, and innovate; and an ability to leverage complexity to compete. Standout companies are using projects as the hotbed of creativity – so that means BAs and PMs have to step up their game. According to the 2011 CHAOS Report from The Standish Group, only 37% of projects delivered on time, on budget, with required features and functions.

The Cause: Gaps in enterprise business analysis and complexity management
The Cost: USD 1.22 trillion/year in the US and USD 500 billion/month worldwide in IT project waste
The Opportunity Cost: “If we could solve the problem of IT failure, the US could increase GDP by USD 1 trillion/yr.” according to Roger Sessions, a recognized expert in enterprise architecture and author of Simple Architectures for Complex Enterprises.

We need to fundamentally change the way we do projects so that 80% of projects are on time, budget and scope (see Figure 1). But we also need to focus on innovative solutions, not incremental changes to business as usual. And we need to bring about value to the customer and wealth to the organization – otherwise, why are we investing in the project? This is where the BA comes in – constantly focusing on value and leveraging complexity to foster creativity.

Figure 1: New Project Approach

Does the business analyst role change, either significantly or subtly, with highly complex projects? If so, how? Our framework for dealing with complex projects consists of four distinct activities (see Figure 2):

Diagnose Project Complexity
Assign Competent Leaders
Select the appropriate project management approach
Manage complexity dimensions

This article in the series will examine steps 1 – 3.

Figure 2: Project Complexity Framework

Step #1: Diagnose Project Complexity

The first step in understanding the level of complexity of your project is to assess each complexity dimension. Use the Project Complexity Model depicted in Figure 3. Facilitate your project team leads to agreement on which cells most closely describe your project for each complexity dimension. Then apply the project complexity formula to determine the complexity profile of your project. In my experience, the actual complexity of projects exceeds the team’s initial assessment prior to applying the model.

PROJECT COMPLEXITY MODEL 2.0

Complexity Dimensions	Project Profile
	Independent Project	Moderately Complex Project	Highly Complex Project	Highly Complex Program “Megaproject”
Size/Time/Cost	Size: 3–4 team members Time: < 3 months Cost: < $250K	Size: 5–10 team members Time: 3–6 months Cost: $250–$1M	Size: > 10 team members Time: 6 – 12 months Cost: > $1M	Size: Multiple diverse teams Time: Multi-year Cost: Multiple Millions
Team Composition and Past Performance	PM: competent, experienced Team: internal; worked together in past Methodology: defined, proven	PM: competent, inexperienced Team: internal and external, worked together in past Methodology: defined, unproven Contracts: straightforwar Contractor Past Performance: good	PM: competent; poor/no experience with complex projects Team: internal and external, have not worked together in past Methodology: somewhat defined, diverse Contracts: complex Contractor Past Performance: unknown	PM: competent, poor/no experience with megaprojects Team: complex structure of varying competencies and performance records (e.g., contractor, virtual, culturally diverse, outsourced teams)Methodology: undefined, diverse Contracts: highly complex Contractor Past Performance: poor
Urgency and Flexibility of Cost, Time, and Scope	Scope: minimized Milestones: small Schedule/Budget: flexible	Scope: achievable Milestones: achievable Schedule/Budget: minor variations	Scope: over-ambitious Milestones: over-ambitious, firm Schedule/Budget: inflexible	Scope: aggressive Milestones: aggressive, urgent Shedule/Budget: aggressive
Clarity of Problem, Opportunity, Solution	Objectives: defined and clear Opportunity/Solution: easily understood	·Objectives: defined, unclear Opportunity/Solution: partially understood	Objectives: defined, ambiguous Opportunity/Solution: ambiguous	Objectives: undefined, uncertain Opportunity/Solution: undefined, groundbreaking, unprecedented
Requirements Volatility and Risk	Customer Support: strong Requirements: understood, straightforward, stable Functionality: straightforward	Customer Support: adequate Requirements: understood, unstable Functionality: moderately complex	Customer Support: unknown Requirements: poorly understood, volatile Functionality: highly complex	Customer Support: inadequate Requirements: uncertain, evolving Functionality: many complex “functions of functions”
Strategic Importance, Political Implications, Stakeholders	Executive Support: strong Political Implications: none Communications: straightforward Stakeholder Management: straightforward	Executive Support: adequate Political Implications: minor Communications: challenging Stakeholder Management: 2–3 stakeholder groups	Executive Support: inadequate Political Implications: major, impacts core mission Communications: complex Stakeholder Management: multiple stakeholder groups with conflicting expectations; visible at high levels of the organization	Executive Support: unknown Political Implications: impacts core mission of multiple programs, organizations, states, countries; success critical for competitive or physical survival Communications: arduous Stakeholder Management: multiple organizations, states, countries, regulatory groups; visible at high internal and external levels
Level of Change	Organizational Change: impacts a single business unit, one familiar business process, and one IT system Commercial Change: no changes to existing commercial practices	Organizational Change: impacts 2–3 familiar business units, processes, and IT systems Commercial Change: enhancements to existing commercial practices	Organizational Change: impacts the enterprise, spans functional groups or agencies; shifts or transforms many business processes and IT systems Commercial Change: new commercial and cultural practices	Organizational Change: impacts multiple organizations, states, countries; transformative new venture Commercial Change: ground-breaking commercial and cultural practices
Risks, Dependencies, and External Constraints	Risk Level: low External Constraints: no external influences Integration: no integration issues Potential Damages: no punitive exposure	Risk Level: moderate External Constraints: some external factors Integration: challenging integration effort Potential Damages: acceptable exposure	Risk Level: high External Constraints: key objectives depend on external factors Integration: significant integration required Potential Damages: significant exposure	Risk Level: very high External Constraints: project success depends largely on multiple external organizations, states, countries, regulators Integration: unprecedented integration effort Potential Damages: unacceptable exposure
Level of IT Complexity	Technology: technology is proven and well-understood IT Complexity: application development and legacy integration easily understood	Technology: technology is proven but new to the organization IT Complexity: application development and legacy integration largely understood	Technology: technology is likely to be immature, unproven, complex, and provided by outside vendors IT Complexity: application development and legacy integration poorly understood	Technology: technology requires groundbreaking innovation and unprecedented engineering accomplishments IT Complexity: multiple “systems of systems” to be developed and integrated

Figure 3: Project Complexity Model 2.0

Then apply the formula below, Figure 4 to diagnose the complexity level of your project.

PROJECT COMPLEXITY FORMULA

Highly Complex Program

“Megaproject”

Highly Complex Project

Moderately Complex

Independent

Size: Multiple diverse teams, Time: Multi-year, Cost: Multiple Millions

2 or more in the Highly Complex Program/Megaproject column

Organizational Change: impacts the enterprise, spans functional groups or agencies, shifts or transforms many business processes and IT systems

3 or more categories in the Highly Complex Project column

And

No more than 1 category in the Highly Complex Program/Megaproject column

3 or more categories in the Moderately Complex Project column

No more than 2 categories in the Highly Complex Project column and

No more than 2 categories in the Moderately Complex Project column

And

No categories in the Highly Complex Project or the Highly Complex Program/Megaproject column

Figure 4: Project Complexity Formula

Step #2: Assign Competent Project Leaders

Complex projects require seasoned leaders, and the use of a shared leadership model (see Figure 5). The core project leadership team consists of the PM, BA, Chief Architect, Development Lead and a Business Visionary, each taking the lead when a particular expertise is needed.

Figure 5: Shared Leadership Model

Once the project complexity is known, it is imperative that appropriately skilled and experienced individuals are assigned to key leadership positions. Obviously, BAs need more sophisticated skills as they move from low complexity projects, to enterprise, strategic and innovation projects. The first order of business is for the organization to understand their BA Workforce. Check out the blog site: http://baassessmentmatters.blogspot.com/ posting on March 5^th entitled “Calling All BA Practice Leads!” It discusses how BA Practice Leads ensure their organizations have an appropriately skilled BA workforce (see Figure 6) possessing the capabilities needed to successfully deliver complex new business solutions that meet 21^st century business needs.

Figure 6: BA Workforce Capability Model

The BA Manager or Practice Lead then assigns BAs (and working with other managers, assigns other project leaders) based on the complexity profile of the project at hand (Figure 7). If the project leads’ capabilities are lower than the complexity of the project requires, it is almost certain that you will have a challenged and/or failed project.

Figure 7: Make Appropriate Leadership Assignments

Step #3: Select the Project Approach

As projects have become more complex, project cycles have evolved. Project cycles models are not interchangeable; one size does not fit all. Project cycles can be categorized into three broad types:

Linear: used when the business problem, opportunity, and solution are clear, no major changes are expected, and the effort is considered to be routine. A linear cycle is typically used for maintenance, enhancement, and continuous process improvement projects. It is also used for development projects when requirements are well understood and stable, as in shrink-wrap software development projects.
Adaptive: used when the business problem, opportunity, and solution are unclear and the schedule is aggressive. An adaptive cycle is typically used for new technology development, new product development, or complex business transformation projects.
Extreme: used when the business objectives are unclear or the solution is undefined. An extreme cycle is typically used for research and development, new technology, and innovation projects.[4]

Figure 8 shows the differences between linear and more adaptive methods.

Linear Methods

Adaptive Methods

Industrial-age thinking
Plan based
Distinct life cycle phases
Tasks completed in orderly sequence
Assumes predictability
Lays out development steps
Stresses the importance of requirements
Only firm basic requirements that are not expected to change (aka high-level requirements) and a release plan up front
Many rapid planning and development cycles
Produces small batches of tailored products on a tight schedule
Evolution of requirements with each planning and development cycle
Constant evaluation of the evolving product
Constant evaluation of the value of functions in backlog

Figure 8: Linear vs. Adaptive Methods

As we move along the complexity continuum from independent, low complexity predictable projects to highly complex projects with lots of uncertainty, we also move along the spectrum of project cycle types. A linear approach works for a simple, straightforward project; whereas, adaptive, and extreme approaches are used to manage the uncertainties of increasingly complex efforts (see Figure 9).

Figure 9: Project Complexity Mapped to Project Cycle Approaches

Low-Complexity Projects: Traditional Waterfall Methods

The traditional role of the business analyst does not need to change much to successfully execute activities on low-complexity projects. The linear Waterfall Model is appropriate (see Figure 10). However, to optimize the business analyst role, it is wise to adopt some of the principles of agile and iterative development for even low-complexity endeavors:

Prototype for requirements understanding, to reduce risk, and to prove a concept
Involve the business and keep the business analyst as a member of the core project leadership team throughout the project
Continuously validate, evolve, and improve requirements throughout the project.

Figure 10: The Waterfall Model

Moderately Complex Projects: Agile Methods

There’s no question about it: agile methods expedite the product development process, especially for products that are software intensive. Agile is an adaptive, streamlined model, based on having only essential people work in tight-knit teams for quick and efficient results (see Figure 11). As we’ve seen, one very important member of the team is the business analyst; if companies hope to achieve strategic goals, they need someone who is focused on the business value expected from the project outcomes. The business analyst provides guidance before funds are invested, during a project, and after the solution is delivered. She continually focuses on the evolving business requirements and serves as the steward of the business benefits.[5]

Figure 11: The Agile Model

Through leadership and collaboration, the project manager and business analyst guide the agile team, ensuring that it is both efficiently and effectively run and that it adds significant long-term benefits for the company with each iteration. The business analyst plays close attention to the original business case, recommending the project be terminated when the ROI has been realized.

Firm Basic Requirements

A business analyst’s main priority when she is first attached to a specific project is to elicit firm, basic business requirements (what we used to call high-level requirements, which outline the breadth of requirements and which we do not expect to change), to collaboratively determine the most feasible solution, and then to categorize releases into valuable features and functions. Then each release is initially described in enough detail to determine its cost versus its benefits, thus developing an ROI for each release.

Knowing what it will take to deliver each individual component of the solution as well as what the return will be to the organization, the development team can then build components or features based on business value, delivering the highest-value features first. As the project moves through the release schedule, the business analyst elaborates the requirements in enough detail to meet the development team’s needs for each release.

An Eye on the Business Value

As an agile project progresses through its life cycle, the team continually learns new information. It becomes clearer how many resources will be needed to perform detailed design, construction, and tests for each release, how much risk there is to the project, and how the risk needs to be managed. Accordingly, it is important to go back and check original assumptions about business value and costs to develop and operate the new solution to see if they are still true, or if the original business case has been compromised.

Validation after Every Release

By being involved during the development process, business analysts can validate that new components are actually meeting business needs and that the business case is still sound. They also take information to other groups outside of the agile team to further corroborate that the inevitable changes have the support of other stakeholders.

Organizational Transition Requirements

The operational environment needs to be analyzed and assessed before the solution components are implemented. Perhaps there will be a need for reorganization, retooling, retraining, or acquisition of new staff. Working with management, the business analyst helps to ensure the organization is prepared for the impact of the changes and can support the release plan. That way, when the complete solution is delivered, it can be operated efficiently and effectively.

Lighter Requirements

Agile requirements are typically “lighter” than those developed for linear project models. Requirements are visually documented whenever possible. The wise business analyst uses modeling to manage complexity. Less formal user stories (a high-level description of solution behavior) may suffice, as opposed to use cases.

Advanced Skills

Advanced skill development is required for business analysts who are working on agile projects. They need to develop new or higher-level leadership skills, including expert facilitation, coaching, collaborative decision-making, and team development. The analyst also needs to have a good understanding of software architecture and be proficient in decoupling the breadth of the solution from the depth of the solution into feature-driven requirements.

Highly Complex Projects, Programs, and Megaprojects: Extreme Methods

Welcome a certain amount of complexity and churn because it creates a chemical reaction that jars creative thinking.

—Colleen Young, VP and distinguished analyst and IT adviser, Gartner, Inc.

Highly complex projects offer the greatest opportunities for creativity: complexity breeds creativity. But the business analyst must understand the nature of complexity to leverage complexity to foster innovation. Complexity is one of those words that is difficult to define. Some say complexity is the opposite of simplicity; others say complicated is the opposite of simple, while complex is the opposite of independent.

Since complex projects are by their very nature unpredictable, it is imperative that the project team keep its options open as long as possible, building those options into the project approach. This approach requires that considerable time be dedicated to researching and studying the business problem or opportunity; conducting competitive, technological, and benchmark studies; defining dependencies and interrelationships; and identifying potential options to meet the business need or solve the business problem. In addition, the team experiments with alternative solutions and analyzes the economic, technical, operational, cultural, and legal feasibility of each option until it becomes clear which solution option has the highest probability of success. When the opportunity is unclear and the solution is unknown, traditional linear approaches simply will not work.

Last-Responsible-Moment Design Decisions

On highly complex projects, it is important to separate design from construction. The key is to use expert resources and allow them to spend enough time experimenting before they make design decisions; the construction activities will thereby become much more predictable. Linear methods might then be appropriate during the construction phase of the project.

Models for adaptive project management are still emerging. We suggest two that are designed to provide iterative learning experiences, adapt and evolve as more is learned, allow analysis and experimentation to determine solution design viability, and delay decision-making as long as possible (that is, until the last responsible moment, the point at which further delays will put the project at risk): the adaptive evolutionary prototyping model and the eXtreme project management model. There are significant differences between the adaptive and eXtreme approaches (see Figure 12).

Adaptive Methods

eXtreme Methods

Many rapid planning and development cycles
Produce small batches of tailored products on a tight schedule
Constant evaluation of evolving product
Constant evaluation of the value of functions in backlog

· Keep your options open

◦ Build options into the approach

· Discover, experiment, create, innovate

◦ Analyze problem/opportunity

◦ Conduct competitive, technical, and benchmark studies

◦ Brainstorm to identify all possible solutions

◦ Analyze feasibility of each option

◦ Design and test multiple solutions

Figure 12: Adaptive vs. Extreme Methods

Evolutionary Prototyping Model

The keep-our-options-open approach often involves rapid prototyping—a fast build of a solution component to prove that an idea is feasible—which is typically used for high-risk components, requirements understanding, or proof of a concept.

Evolutionary prototyping is quite effective for multiple iterations of requirements elicitation, analysis, and solution design. Iteration is the best defense against uncertainty because with each iteration, the technical and business experts examine the prototype and glean more information and certainty about functions that are built into the next iteration.

The strength of prototyping is that customers work closely with the project team, providing feedback on each iteration (see Figure 13). If requirements are unclear and highly volatile, prototyping helps bring the business need into view.

Figure 13: Adaptive Evolutionary Prototype Model

eXtreme Project Management Model

An extreme project is a complex, high-speed, self-correcting venture during which people interact in search of a desirable result under conditions of high uncertainty, high change, and high stress.

—Doug DeCarlo, author and lecturer,

Extreme Project Management

eXtreme project management is sometimes also called radical project management. Some equate it to scaled-up agile methods. The approach consists of a number of short, experimental iterations designed to determine project goals and identify the most viable solution. As in the agile model, eXtreme project management requires that the customer be involved every step of the way until the solution emerges—a practice that involves many iterations. Like the iterative Spiral Model, the eXtreme model terminates after the solution is found (or when the sponsor is unwilling to fund any more research); the project team then transitions to one of the other appropriate models. One variation of the eXtreme Model spends a considerable amount of time in discovery, then prototypes, then transitions to modular development (see Figure 14).

Figure 14: eXtreme Model

Challenges will arise at every turn, because it can be difficult to:

Know how long to keep your options open
Build options into the approach without undue cost and time
Gather the right group of experts to discover, experiment, create, innovate, and:

◦ Analyze the problem/opportunity

◦ Conduct competitive, technical, and benchmark studies

◦ Brainstorm to identify all possible solutions

◦ Analyze the feasibility of each option

◦ Design and test multiple solutions.

Operating on the Edge of Chaos

Conventional business analysis practices that assume a stable and predictable environment encourage us to develop all the requirements up front, get them approved, and then fiercely control changes. As we have seen, conventional linear project cycles work well and should be used for predictable, repeatable projects; however, this approach has proven to be no match for chaotic 21^st-century projects. Figure 15 compares the characteristics of projects on which conventional linear practices can be successfully used with the characteristics of projects that require a more adaptive model. A blend of the linear, adaptive, and eXtreme models is almost always the answer. The trick is to know when and how to apply which approach.

Conventional linear approaches work well for projects that…	Adaptive approaches work well for projects that…
Are structured, orderly, disciplined	Are spontaneous, disorganized
Rely heavily on plans	Evolve as more information is known
Are predictable, well defined, repeatable	Are surprising, ambiguous, unique, unstable, innovative, creative
Are built in an unwavering environment	Are built in a volatile and chaotic environment
Use proven technologies	Use unproven technologies
Have a realistic schedule	Have an aggressive schedule; there is an urgent need

Figure 15: Conventional vs. Adaptive Approaches

What exactly does it mean to operate on the edge of chaos? Complex systems fluctuate between a static state of equilibrium and an adaptive state of chaos. If a system remains static, it will eventually result in paralysis and death. Whereas, if a complex system is in chaos, it is unable to function. So, here is the genius of complexity: it breeds and nourishes creativity, as complex systems adapt to changes in the environment for survival. Complexity scientists tell us that the most creative and productive state is at the edge of chaos. (Refer to figure 16.) Therefore, complex project teams must operate at the edge of chaos for a time in order to allow the creative process to flourish. The business analyst assigned to a complex project must use adaptive business analysis methods to foster an environment where creativity is possible. The next article in this series explores the business analyst as creative leader of complex projects who are living on the edge.

Figure 16: The Edge of Chaos: the Most Creative State

Putting It All Together: What Does This Mean to the Business Analyst?

A business analyst who is an asset to highly complex projects is comfortable with lots of uncertainty and ambiguity in the early stages of a project. She leads and directs plenty of sessions of brainstorming, alternative analysis, experimentation, prototyping, out-of-the-box thinking, and trial and error, and encourages the team to keep options open until they have identified an innovative solution that will allow the organization to leap ahead of the competition. The BA who does not embrace complexity does so at her own peril.

The articles in this series are adapted with permission from The Enterprise Business Analyst: Developing Creative Solutions to Complex Business Problems by Kathleen B. Hass, PMP. © 2011 by Management Concepts, Inc. All rights reserved. The Enterprise Business Analyst: Developing Creative Solutions to Complex Business Problems

About the Author

Kathleen B. (Kitty) Hass, PMP

Senior Practice Consultant

Kathleen Hass & Associates, Inc.

Email: [email protected]

Website: www.kathleenhass.com

Blog: http://baassessmentmatters.blogspot.com/

Twitter: @ BA_Assessment @KathleenHass1

Kitty is the president of her consulting practice specializing in enterprise business analysis, complex project management, and strategy execution. She is a prominent presenter at industry conferences, author and facilitator. Her BA Assessment Practice is the gold standard in the industry. KHass BA Assessments:

Appraise both BA organizational maturity and individual/workforce BA capability based on four-stage reference models
Present results that are continuously examined for reliability and validity by Lori Lindbergh, PhD, Senior Researcher and Psychometrician , Lorius, llc
Benchmark results against a global data base of BAs performing comparable work
Align with the IIBA BABOK^® and the BA Competency Model^®
Align with standards and best practices for quality and fairness in educational and psychological assessment
Are based on the skills and knowledge needed to work successfully on the complexity of current project assignments
Examine critical relationships between competency, project complexity, and project outcomes.

In addition to assessments, Kitty’s expertise includes implementing and managing PMOs and BACOEs. She has over 25 years of experience providing professional services to Federal agencies, the intelligence community, and Fortune 500 companies. Kitty is a Director on the IIBA Board and Chair of the IIBA Board Nominations Committee. She has also authored numerous white papers and articles on leading-edge business practices, the renowned series entitled, Business Analysis Essential Library, and the PMI Book of the Year, Managing Project Complexity – A New Model.

[1] Tom Friedman, Michael Mandelbaum, That Used to be us: How America Fell Behind in the World it Invented and How we can Come Back, 2011.

[2] Ibid., p. 134.

, The New York Times, January 21, 2012. Online at: http://www.nytimes.com/2012/01/22/business/apple-america-and-a-squeezed-middle-class.html?pagewanted=4&ref=charlesduhigg

[4]. Robert K. Wysocki, Effective Project Management: Traditional, Adaptive, Extreme, 4^th ed. (Indianapolis: Wiley Publishing, Inc., 2007), 48.

[5]. Kathleen B. Hass, “An Eye for Value: What the Business Analyst Brings to the Agile Team,” Project Management World Today (June 2007), 1-5.

The Adaptive Business Analyst – As Complexity Increases, the BA Adapts

Written by Kathleen B. Hass, PMP on March 5, 2012. Posted in Articles. 1 Comment on The Adaptive Business Analyst – As Complexity Increases, the BA Adapts

Facebook	Didn’t exist
Twitter	Was a sound
LinkedIn	Was a prison
A Cloud	Was in the sky
An Application	Was something you used to get into college
4G	Was a parking space
Skype	Was a typo [1]

Fast forward to now. Traditional work has been commoditized. Anyone with an idea and a little moxie can use their laptop to set in motion a virtual new entity. You can go to:

Taiwan	For product design
Alibaba in China	For low-cost manufacturing
Amazon.com	For delivery and fulfillment
Craigs List	To do your accounting
Freelance.com	To do your logo [2]

If this isn’t bad enough, the heart and soul of middle class jobs are disappearing in the U.S. Consider this: When Apple began manufacturing the iPhone, the company estimated that it would take nine months to find 8,700 qualified industrial engineers in the U.S. to oversee and guide the 200,000 assembly-line workers eventually involved in manufacturing iPhones. In China, it took 15 days. [3] Result: we lost 200,000 iPhone manufacturing jobs.

What does all this Mean to the Business Analyst?

The Cause: Gaps in enterprise business analysis and complexity management
The Cost: USD 1.22 trillion/year in the US and USD 500 billion/month worldwide in IT project waste
The Opportunity Cost: “If we could solve the problem of IT failure, the US could increase GDP by USD 1 trillion/yr.” according to Roger Sessions, a recognized expert in enterprise architecture and author of Simple Architectures for Complex Enterprises.

Figure 1: New Project Approach

Diagnose Project Complexity
Assign Competent Leaders
Select the appropriate project management approach
Manage complexity dimensions

This article in the series will examine steps 1 – 3.

Figure 2: Project Complexity Framework

Step #1: Diagnose Project Complexity
The first step in understanding the level of complexity of your project is to assess each complexity dimension. Use the Project Complexity Model depicted in Figure 3. Facilitate your project team leads to agreement on which cells most closely describe your project for each complexity dimension. Then apply the project complexity formula to determine the complexity profile of your project. In my experience, the actual complexity of projects exceeds the team’s initial assessment prior to applying the model.

PROJECT COMPLEXITY MODEL 2.0

Figure 3: Project Complexity Model 2.0
© Kathleen B. Hass and Associates, Inc.

Then apply the formula below, Figure 4 to diagnose the complexity level of your project.

PROJECT COMPLEXITY FORMULA

Figure 4: Project Complexity Formula
© Kathleen B. Hass and Associates, Inc.

Step #2: Assign Competent Project Leaders
Complex projects require seasoned leaders, and the use of a shared leadership model (see Figure 5). The core project leadership team consists of the PM, BA, Chief Architect, Development Lead and a Business Visionary, each taking the lead when a particular expertise is needed.

Figure 5: Shared Leadership Model

Figure 6: BA Workforce Capability Model

Figure 7: Make Appropriate Leadership Assignments

Step #3: Select the Project Approach
As projects have become more complex, project cycles have evolved. Project cycles models are not interchangeable; one size does not fit all. Project cycles can be categorized into three broad types:

Linear: used when the business problem, opportunity, and solution are clear, no major changes are expected, and the effort is considered to be routine. A linear cycle is typically used for maintenance, enhancement, and continuous process improvement projects. It is also used for development projects when requirements are well understood and stable, as in shrink-wrap software development projects.
Adaptive: used when the business problem, opportunity, and solution are unclear and the schedule is aggressive. An adaptive cycle is typically used for new technology development, new product development, or complex business transformation projects.
Extreme: used when the business objectives are unclear or the solution is undefined. An extreme cycle is typically used for research and development, new technology, and innovation projects. [4]

Figure 8 shows the differences between linear and more adaptive methods.

Linear Methods	Adaptive Methods
Industrial-age thinking Plan based Distinct life cycle phases Tasks completed in orderly sequence Assumes predictability Lays out development steps Stresses the importance of requirements	Only firm basic requirements that are not expected to change (aka high-level requirements) and a release plan up front Many rapid planning and development cycles Produces small batches of tailored products on a tight schedule Evolution of requirements with each planning and development cycle Constant evaluation of the evolving product Constant evaluation of the value of functions in backlog

Figure 8: Linear vs. Adaptive Methods

Figure 9: Project Complexity Mapped to Project Cycle Approaches
© Kathleen B. Hass and Associates, Inc.

Low-Complexity Projects: Traditional Waterfall Methods
The traditional role of the business analyst does not need to change much to successfully execute activities on low-complexity projects. The linear Waterfall Model is appropriate (see Figure 10). However, to optimize the business analyst role, it is wise to adopt some of the principles of agile and iterative development for even low-complexity endeavors:

Prototype for requirements understanding, to reduce risk, and to prove a concept
Involve the business and keep the business analyst as a member of the core project leadership team throughout the project
Continuously validate, evolve, and improve requirements throughout the project.

Figure 10: The Waterfall Model

Moderately Complex Projects: Agile Methods
There’s no question about it: agile methods expedite the product development process, especially for products that are software intensive. Agile is an adaptive, streamlined model, based on having only essential people work in tight-knit teams for quick and efficient results (see Figure 11). As we’ve seen, one very important member of the team is the business analyst; if companies hope to achieve strategic goals, they need someone who is focused on the business value expected from the project outcomes. The business analyst provides guidance before funds are invested, during a project, and after the solution is delivered. She continually focuses on the evolving business requirements and serves as the steward of the business benefits. [5]

Figure 11: The Agile Model

Firm Basic Requirements
A business analyst’s main priority when she is first attached to a specific project is to elicit firm, basic business requirements (what we used to call high-level requirements, which outline the breadth of requirements and which we do not expect to change), to collaboratively determine the most feasible solution, and then to categorize releases into valuable features and functions. Then each release is initially described in enough detail to determine its cost versus its benefits, thus developing an ROI for each release.

An Eye on the Business Value
As an agile project progresses through its life cycle, the team continually learns new information. It becomes clearer how many resources will be needed to perform detailed design, construction, and tests for each release, how much risk there is to the project, and how the risk needs to be managed. Accordingly, it is important to go back and check original assumptions about business value and costs to develop and operate the new solution to see if they are still true, or if the original business case has been compromised.

Validation after Every Release
By being involved during the development process, business analysts can validate that new components are actually meeting business needs and that the business case is still sound. They also take information to other groups outside of the agile team to further corroborate that the inevitable changes have the support of other stakeholders.

Organizational Transition Requirements
The operational environment needs to be analyzed and assessed before the solution components are implemented. Perhaps there will be a need for reorganization, retooling, retraining, or acquisition of new staff. Working with management, the business analyst helps to ensure the organization is prepared for the impact of the changes and can support the release plan. That way, when the complete solution is delivered, it can be operated efficiently and effectively.

Lighter Requirements
Agile requirements are typically “lighter” than those developed for linear project models. Requirements are visually documented whenever possible. The wise business analyst uses modeling to manage complexity. Less formal user stories (a high-level description of solution behavior) may suffice, as opposed to use cases.

Advanced Skills
Advanced skill development is required for business analysts who are working on agile projects. They need to develop new or higher-level leadership skills, including expert facilitation, coaching, collaborative decision-making, and team development. The analyst also needs to have a good understanding of software architecture and be proficient in decoupling the breadth of the solution from the depth of the solution into feature-driven requirements.

Highly Complex Projects, Programs, and Megaprojects: Extreme Methods
Welcome a certain amount of complexity and churn because it creates a chemical reaction that jars creative thinking,
—Colleen Young, VP and distinguished analyst and IT adviser, Gartner, Inc.

Last-Responsible-Moment Design Decisions
On highly complex projects, it is important to separate design from construction. The key is to use expert resources and allow them to spend enough time experimenting before they make design decisions; the construction activities will thereby become much more predictable. Linear methods might then be appropriate during the construction phase of the project.

Adaptive Methods	eXtreme Methods
Many rapid planning and development cycles Produce small batches of tailored products on a tight schedule Constant evaluation of evolving product Constant evaluation of the value of functions in backlog	Keep your options open Build options into the approach Discover, experiment, create, innovate Analyze problem/opportunity Conduct competitive, technical, and benchmark studies Brainstorm to identify all possible solutions Analyze feasibility of each option Design and test multiple solutions

Figure 12: Adaptive vs. Extreme Methods

Evolutionary Prototyping Model
The keep-our-options-open approach often involves rapid prototyping—a fast build of a solution component to prove that an idea is feasible—which is typically used for high-risk components, requirements understanding, or proof of a concept.

Figure 13: Adaptive Evolutionary Prototype Model
© Kathleen B. Hass and Associates, Inc.

eXtreme Project Management Model
An extreme project is a complex, high-speed, self-correcting venture during which people interact in search of a desirable result under conditions of high uncertainty, high change, and high stress. —Doug DeCarlo, author and lecturer, Extreme Project Management

Figure 14: eXtreme Model
© Kathleen B. Hass and Associates, Inc.

Challenges will arise at every turn, because it can be difficult to:

Know how long to keep your options open
Build options into the approach without undue cost and time
Gather the right group of experts to discover, experiment, create, innovate, and:
- Analyze the problem/opportunity
- Conduct competitive, technical, and benchmark studies
- Brainstorm to identify all possible solutions
- Analyze the feasibility of each option
- Design and test multiple solutions.

Operating on the Edge of Chaos
Conventional business analysis practices that assume a stable and predictable environment encourage us to develop all the requirements up front, get them approved, and then fiercely control changes. As we have seen, conventional linear project cycles work well and should be used for predictable, repeatable projects; however, this approach has proven to be no match for chaotic 21^st-century projects. Figure 15 compares the characteristics of projects on which conventional linear practices can be successfully used with the characteristics of projects that require a more adaptive model. A blend of the linear, adaptive, and eXtreme models is almost always the answer. The trick is to know when and how to apply which approach.

Conventional linear approaches work well for projects that…	Adaptive approaches work well for projects that…
Are structured, orderly, disciplined	Are spontaneous, disorganized
Rely heavily on plans	Evolve as more information is known
Are predictable, well defined, repeatable	Are surprising, ambiguous, unique, unstable, innovative, creative
Are built in an unwavering environment	Are built in a volatile and chaotic environment
Use proven technologies	Use unproven technologies
Have a realistic schedule	Have an aggressive schedule; there is an urgent need

Figure 15: Conventional vs. Adaptive Approaches

Figure 16: The Edge of Chaos: the Most Creative State

Putting It All Together: What Does This Mean to the Business Analyst?
A business analyst who is an asset to highly complex projects is comfortable with lots of uncertainty and ambiguity in the early stages of a project. She leads and directs plenty of sessions of brainstorming, alternative analysis, experimentation, prototyping, out-of-the-box thinking, and trial and error, and encourages the team to keep options open until they have identified an innovative solution that will allow the organization to leap ahead of the competition. The BA who does not embrace complexity does so at her own peril.

Appraise both BA organizational maturity and individual/workforce BA capability based on four-stage reference models
Present results that are continuously examined for reliability and validity by Lori Lindbergh, PhD, Senior Researcher and Psychometrician , Lorius, llc
Benchmark results against a global data base of BAs performing comparable work
Align with the IIBA BABOK^® and the BA Competency Model^®
Align with standards and best practices for quality and fairness in educational and psychological assessment
Are based on the skills and knowledge needed to work successfully on the complexity of current project assignments
Examine critical relationships between competency, project complexity, and project outcomes.

Don’t forget to leave your comments below.

[1] Tom Friedman, Michael Mandelbaum, That Used to be us: How America Fell Behind in the World it Invented and How we can Come Back, 2011.
[2] Ibid., p. 134.
[3] How the U.S. Lost Out on iPhone Work, The New York Times, January 21, 2012. Online at: http://www.nytimes.com/2012/01/22/business/apple-america-and-a-squeezed-middle-class.html?pagewanted=4&ref=charlesduhigg
[4] Robert K. Wysocki, Effective Project Management: Traditional, Adaptive, Extreme, 4^th ed. (Indianapolis: Wiley Publishing, Inc., 2007), 48.
[5] Kathleen B. Hass, “An Eye for Value: What the Business Analyst Brings to the Agile Team,” Project Management World Today (June 2007), 1-5.

A Cornered CIO’s Strategy: Protracted Border Wars With The Business

Written by Abid Mustafa on December 20, 2011. Posted in Articles. 1 Comment on A Cornered CIO’s Strategy: Protracted Border Wars With The Business

It is an established fact that between Business and IT, relations are hardly ever harmonious. Moreover, each one endeavors to blame the other when things go wrong and both scramble to take credit when things go right. When questioned about why Business and IT find it so difficult to get on, claims of being misunderstood is the rallying cry for both departments and often used as the first line of defense to conceal ulterior motives, incompetence and failure.

Interaction between the two departments can vary depending upon the political dynamics of the organization, and the individual personalities of the CIO and CBOs (Chief Business Officers). However, where the relationship is heavily tilted in the favor of the business, IT can find itself in a tough predicament. Continuously flooded with a tsunami of business requests and expected to deliver results in the face of never-ending cost rationalization drives; CIO’s often struggle to meet day-to-day deadlines. Increasingly, CIOs find themselves isolated at the executive level and are coerced to do ‘more with less’. Capitulated and brow-beaten by the business executives, the CIOs dare say no!—for the consequences maybe too grave to contemplate. Gone is the spare time to think about strategy, optimize processes, improve the delivery methodology and lift the morale of over-worked IT workforce. The only recourse left for CIOs is to dream better times and make do with what they have.

CIOs need not to accept this fate. In fact, if they exercise their options correctly, they can turn the tables on the business and move from being viewed as an obstacle to an enabler of business value. But first, the astute CIO must get his/her own house in order. This often implies, finding the time and space to think and act strategically, and to restructure the IT department. This is no mean feat, especially when the business enjoys the upper hand amongst the executive team, and expects IT to deliver to its beckoning call.

An effective course of action is to adroitly manipulate the volume of requests from the business. This does not imply that the CIO has to look at implementing industry best practice demand management techniques, even though it is essential and part of a long term solution. The immediate requirement is for the CIO to create enough time and space to think strategically and implement important decisions that produce a sea change in the IT landscape and bolster its capability to deliver real value to the business.

One way to do this is to make the entry point into IT a legitimate choke point for the business i.e. to use business language to increase the time it takes to sign off requirements. Typically, IT requirement teams do not have the mindset or the skills to engage in endless border wars, which are intended to sap the energy in this case of the business units. Yes, the IT requirements management team is staffed with competent business analysts who specialize in low-level business requirements, but more often than not, the business analysts are not considered domain experts by the business and are usually treated with contempt. Moreover, the business analysts are in no position to question business’s ‘holy grail’ i.e. the high-level business requirements.

To reverse this equation, it is important to augment the IT requirements management team with domain experts, who understand the business needs better than the business and have a proven track record of delivering ‘best in class’ business solutions. In other words, these domain experts must be able to challenge, poke holes and make fun of the business requests (while keeping a straight face of course!). So if Sales, HR and Finance are the biggest requestors (IT’s biggest adversaries) of demand then the IT requirements management team should be staffed with domain experts from these three areas. These experts are charged with the responsibility of delaying the processing of the demand by demonstrating flaws in the business requests and quantifying the cost of these flaws. Subsequently, the business will be forced to listen and take note. In this way, the CIO should be able reduce the business demand to his liking, and at the board level is armed with enough information to shoot down any re-requests or threats.

Oddly enough, by inserting domain experts in the requirements management team, the CIO is able to enrich, and fast-track requests from other business units thereby effectively dividing the business into allies and enemies. Hence, at executive meetings the CIO is no longer isolated but supported by other business units who value IT’s contribution.

Therefore by making the entry point into IT a legitimate choking point affords the CIO extra time to make radical changes to the IT landscape. The amount of time devoted to strategizing and re-organizing IT depends to a large degree on the quality of the domain experts and their ability to fight ‘border wars’ with different business units. Given the current recession, it is not too difficult to find C-Level executives on short-term contracts playing such intimidating roles. This short-term strategy is only effective if the CIO can keep the business divided and demonstrate value in rejecting business requests from the most powerful business units.

Don’t forget to leave your comments below.

Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programs and projects. Currently, he is working as a director of corporate programs for a leading telecoms operator in the MENA region.

Business Analyst Interview Techniques for Non-BA Recruiters, Managers and Leads

Written by Barbara Davis on October 11, 2011. Posted in Articles.

The other day I met with a prospective client to talk about an upcoming project. During the meeting it became clear that he was not a Business Analyst and had no real idea of what one should be like. To make matters worse, he wasn’t even a good interviewer. Unfortunately, I see this far too often.

He made some rookie mistakes as far as the interview and really didn’t ask appropriate questions for the role.

Rookie Interviewer Mistake # 1: Closed-Ended Questioning

The first rookie mistake he made was not asking me open-ended questions. You can’t get enough information by asking some if they have ever worked with a particular tool or technology. Asking closed-ended (yes or no) questions will only get you what you want to hear and you won’t be able to make a sound choice in hiring.

You have to ask questions that make the person describe when and where they used it and how they used, or what issues they encountered with it. Only then will you know they actually did work with it.

Non-BA Interviewer Mistake # 1: Asking Inappropriate Questions for Resource Calibre

The next mistake he made focused on my skill set. After asking me if I had ever created any use cases (see rookie mistake #1) and I responded affirmatively, he asked me what goes into a use case. This is a mistake, because for someone with over eleven years of direct experience, you don’t want to ask about the elements, you again want to ask them to give an example of a use case they have created and some of the challenges they faced. You would ask them to tell you why the deliverable is important to a project (why they are created).

Rookie Interviewer Mistake # 2: Incomplete Questioning

Another mistake the potential client made was to ask incomplete questions. At one point there was a pause while he collected his thoughts. Suddenly he asked, “What about functional requirements?” My response (I really wasn’t intending to be cheeky, I swear) was, “What about them?”

I’m a seasoned professional, I’m not about to ramble on answering what I THINK his question is, I’m going to ask for more clarity. What exactly does he want to know about functional requirements and my experiences with them?

Non-BA Interviewer Mistake # 2: Asking Buzz-Word Questions

The other mistake he made was focusing on buzz-words. It was clear he wasn’t an analyst himself because nearly every question he asked used a buzz-word of some flavour or another. That tells me, there was no real depth to his knowledge. Worse, with his closed-ended questioning it was clear he was content with a simple yes or no, so he didn’t really take the opportunity to learn anything new about what an analyst does and improve his ability to interview or recruit new ones in the future.

Unfortunately, this scenario is all too common. It used to frustrate me because where I really wanted the role and felt I did a great job winning the interview, the roles went to more junior and less capable resources. In consulting as a manager placing other analysts, I faced trying to educate the clients about why the analysts I sent them to interview were the right choices.

If you want to know find out if they know any buzz-words (flavour-of-the-week technologies and methodologies), ask them what they think of them and to describe the pros and cons, not if they’ve ever used them.

Rookie/ Non-BA Interviewer Mistake # 3: Interviewing Inappropriate Calibre for the Role

I have to tell you that one of my biggest beefs is fielding calls and emails from recruiters asking me to apply for their roles. Most commonly they are looking for junior, intermediate and senior business analysts to work in a non-team lead capacity. The fact is, I rarely do these roles anymore and my resume screams that fact. So why are they calling me? Quite simply, because they don’t know what they are looking for and one analyst is as good as another. Unfortunately, this forces analysts to compete on price, and with the down-turn in the economy, this has not been pretty.

How much are you willing to pay for quality? Are you willing to bet 70 to 80% of your project budget, that you’re making this mistake?

To put it into perspective, would you scan the resume section of Dice.com or Craig’s List to find a chef if what you really want is someone to cook hotdogs in a vendor cart down-town? Ummm…. My guess is no way! First of all, they’d hang up on you for even asking. Once they get through laughing with their friends about how you made their day, they’re going to pull or dramatically change their resume. Now, you and I know that you can’t possibly ask a chef to be a hotdog vendor anymore than you can go to a Mercedes dealership expecting to spend $5,000 on a new car (unless that’s a monthly or bi-weekly payment!), so why is it so hard to figure out that if a Business Analyst has more than three projects and years of experience they are more intermediate to senior and might be looking to advance their career instead of staying where they are?

You need to ensure that you select the right calibre for the role and quality you expect. Let’s face it you invest in quality and opting for lesser qualified resources without also opting for a senior lead is nuts.

Bad Interviewer Mistake # 1: Showing Intimidation

When you interview someone and it’s clear they have a lot of knowledge in an area, even if it’s an area you share with them, it can be intimidating. The last thing you want to do is show it.

It’s bound to happen that at some point in your interviewing career, you are going to interview others that are more senior than you are. Get over it! Don’t gush in the interview. Don’t suck up to them. Be professional and ask them the same style and line of questions that are appropriate for their calibre.

Ask for more details and examples, even if you don’t know what they are saying and have little way of validating their responses. Look at it this way, by asking for more and more details and clarity to their responses they are one of two things: genuine or really great liars. Since, in reality, really great liars are hard to come by, when you ask for more details and ask the same question in different ways, you will quickly know the difference.

Bad Interviewer Mistake # 2: Being Intimidating

Another common mistake I’ve seen interviewers make is trying to intimidate and challenge the person they are interviewing. If you go into an interview with the attitude that you’re going to catch them in a lie, or they’re not as great as they seem on paper, my best advice is to either sit it out and have someone else do the interview or just cancel it altogether. There is just no excuse for being a bully in an interview.

A couple of years ago, I met with a prospective client whose President only sat and made eye contact with me for about two minutes of the interview. As he paced around the room looking out the windows, he proceeded to tell me that he had hired MBA and PHD grads from Harvard and Oxford to come and work as Business Analysts. He blurted out that they had failed. He demanded that I tell him why. Now, I know his real question (snarky tone and all) was what makes you think you’ll succeed when they failed, but that’s not the question he asked.

I told him that I couldn’t possibly tell him why without more details. I needed to know more about the individuals and work they had been assigned, as well as the processes utilized and the environment in which they worked, and the support (or lack thereof) that they received from management. I didn’t tell him, I was starting to get a pretty good idea (some things you just keep to yourself), but when asked by the recruiter immediately following if I would take the role if offered and I flatly said “No way!”

First, I don’t bother working for such blatant bullies anymore because I know you’ll never be able to please them and succeed. Second, who needs the headache of trying to appease the ego of megalomaniacs over the needs of the business? I’m a business analyst and the needs of the business come first. That means I’m going to tell you things you may or may not agree with, or tell you how to do it better. That’s my job.

How to Interview Business Analysts and Find the Right One

The long and short of it is this, before you ever get into an interview with a business analyst, know the calibre of the person you are going to interview. Read up on business analysis techniques and deliverables and write down some basic questions using the guidelines below.

Calibre-Centric Questions:

Junior

When interviewing a junior business analyst, you are looking for potential more than experience. That means you are looking more for personal characteristics and academic knowledge than detailed stories and explanations of where they have applied the knowledge.

The types of questions you want to ask are about the basic elements of the technologies, deliverables and techniques. You want them to be able to tell you the elements, as well as why the deliverable is important to a project (why they are created). They may not have examples of how they have used them and challenges that they have faced, so they need to know how and why you do them.

Intermediate

When interviewing an intermediate business analyst, you need to start blending your questions to include personal characteristics, academic knowledge and also experience. Remember though that you are considered to intermediate at the three to five years of experience mark, and that doesn’t necessarily correlate to specific levels of experience or even exposure to all deliverables, techniques and tools. You could have worked for three years on a single project and never performed a particular task or created a particular deliverable.

In order to compensate for this, try asking questions about their ability to learn quickly and think on their feet, because this will supplement their experiences thus far and still make them effective on your project.

Senior

When interviewing a senior business analyst, remember that you would expect that a senior can’t become a real senior without having worked on at least two projects, but in reality, most seniors have actually worked on an average of 3.5 projects.

Again, you don’t want to ask about the elements of a given task, deliverable or technique. Go in with the expectation that they must know these things if they are a senior. Instead, to ask them to give examples of deliverables they have created, when and why they chose those ones and then some of the challenges they faced on the project.

Let’s look at this way: if you were interviewing a technical writer, would you ask them if they could read and to tell you the alphabet, or what the elements of a good paragraph are? Of course you wouldn’t.

If you are using the junior line of questioning to challenge a senior, let’s face it you’re probably not going to select them anyway so why bother adding insult on top of it.

Above all, a senior must be able to explain the context of deliverables and techniques. That means you would ask them to tell you why the deliverable or technique is important to a project (why they are created). If you really want to challenge a senior in a positive way, don’t ask them the alphabet, ask them how they would improve the techniques or what they do that makes them unique and more effective than their peers.

Uber-Senior

Uber-seniors are those analysts that other analysts envy and look up to. They have worked on ten or more projects across three or more industries and domains, and can provide strategic advice to the business from an operational as well as technology perspective.

The types of questions you as an uber-senior are more strategy, process and business-centric. Don’t ask them if they’ve ever used MS Project and where, because quite frankly it doesn’t matter if they have or haven’t. What does matter is their ability to adapt and adopt new techniques, tools and technologies in order to get the job done, get it done effectively and efficiently and find ways to improve overall project along the way.

Final Notes:

Look, it’s really important to make the right choice for Business Analyst resources because making the wrong choice can completely derail your project. That means going into the interview with the right frame of mind, a set of questions, asking for more details and finding out how well they will work with the team and business.

Depending on the complexity and criticality of your project, you will need to choose the right analyst(s) for the job, in the same way you would choose the right tool for the job. You wouldn’t choose a hammer if what you had was screws to put the shelving together, you’d choose a screw-driver, and you would make sure the screw driver fit the style of the screw, you would not try to make the screw fit the style of driver.

Don’t forget to leave your comments below.

Barbara Davis has pioneered requirements methodologies by creating the Comprehensive and Robust Requirements Specification Process (CRRSP), as well as methodologies for organizational change, resource management, project management, and building organizational capability. She is a published author and developed & conducted numerous workshops and training sessions with projects including the Requirements Toolkit and the BA Manager’s Blueprint.

Celebritize Yourself

Written by Greta Blash on July 4, 2011. Posted in Articles.

I just finished reading a wonderful book by Marsha Freidman, Celebritize Yourself,[1] which describes a three-step method to increase your visibility at work. I feel that after seven years of work in your profession as a business analyst, you should be recognized as an expert and if you are not, this book will help guide you through the process. Celebritize Yourself is about branding yourself as an expert. This book is not about becoming a Hollywood or TV reality celebrity, but about becoming recognized as an expert or leader in your field.

The three-step method to celebritizing yourself is

1. Write,

2. Speak,

3. Sell.

Write as much and as often as well wherever you can. If fact, everyone who is reading this article is invited to contribute to the Business Analyst Times website: http://www.batimes.com/contributing-to-ba-times.html about your own experiences pertaining to business analysis problems and solutions.

The second step, Speak, is your ability to give presentations to various groups through work-related projects or organizations such as IIBA, Toastmaster, etc. Speaking in front of a group is the number one fear that people have but as a business analyst, you are expected to give presentations about your work so why not take it a little farther by volunteering to give presentations outside of your work environment. The experience will provide you the opportunity to improve your speaking skills.

The third step, Sell, is about selling yourself as a business analyst for future projects or as an authority on business analysis topics so that managers will seek out your opinions. At one company where I worked, I facilitated a weekly brown bag lunch meeting for business analysts where we could share ideas about business analysis topics within actual projects that were currently underway. This proved to be valuable to the newer business analysts and project managers, and also gave me the opportunity to write and speak.

If you look on IIBA’s website, IIBA.org, you will see that IIBA encourages you to give back to your profession by volunteering to write and speak on business analysis topics.

Volunteering activities include:

Willing and able to devote two to six hours per week to IIBA calls and volunteer-related work
Access to email, the Internet, and a word-processing program
Willing and able to attend committee meetings, as scheduled, via conference call or in person.

Before you start, the author recommends that you make a list of your strengths and weaknesses. What are you good at? Is it your organizational and planning skills, your people skills, communications? These are the things that come easy to you and that you thoroughly enjoy. What about your weaknesses? These are the things you struggle with and don’t enjoy and may even try to avoid or pass on to another team member. Do you need to improve on any of these weaknesses? What makes you unique from other project managers when you compare yourself to them?

Next, the author suggests you answer the following questions:

1. What’s Your Vision for Celebrity? Before you can finalize a plan, you must decide where you want the plan to take you. What is your business analysis vision? Make it simple and write it out as to what you want it to be.

2. What is Your Commitment to Your Vision? How determined are you to become a great business analyst? Do you have your CCBA or CBAP certification? Do you attend your local IIBA chapter meetings? Do you communicate with other business analysts? Do you read articles and blogs on Business Analyst Times and respond to what is written there?

3. What is Your Own Unique Message? Defining your message is not always easy nor is it always obvious. But it is important to have a distinctive message about your knowledge, experience and education. What part of it do you enjoy the most and what energizes you to perform the work that you have been assigned?

4. Why Does Your Message Appeal to You? What do you love about being a project manager? Is it the planning, the execution, monitoring and control, or is it the team members or the satisfaction of successfully completing the project that greatly benefits the organization?

5. Why Will Your Message Appeal to Others? It is meaningless to start this journey unless your message can resonate with others. How can you reach out to others to touch their lives and benefit them regarding business analysis?

6. Who is your Target Audience? Who will benefit from your message? Is it other business analysts, stakeholders or students? Identifying your audience is the foundation for your entire plan. That is your personal marketing plan.

7. What’s Your Plan for Celebrity? The plan should contain a defined goal and specific steps that are necessary to achieve it. You should write this, evaluate it and update it frequently before committing to it.

8. When Will You Start? I assume by now that you are enthusiastic and you are thinking about starting your own celebrity journey. Here is a quote from Amelia Earhart: “The most difficult thing is the decision to act; the rest is merely tenacity.” The author suggests that you start out small and add to it as goals are achieved.

9. Have You Picked the Right Teammates? You are looking for individuals that can help support and constructively criticize you and your work. Choose teammates who clearly want to help you succeed. Embrace them and listen to what they have to say, even when it’s critical of your work.

10. How Will You Measure Success? When you consider the time and effort you will put into this, what will you expect to be your reward? Is it recognition from your peers, management or family? Is it the satisfaction of helping others? Only you can provide the answer to this question.

In summary, celebritizing yourself is not a means to an end, but it’s an ongoing journey. It is a path and not a destination. Don’t let the hard work dishearten you or let obstacles stand in your way. If you apply the principle in this article or from the book, you will find the journey becoming easier and your expectations will be met. To walk the path takes a strong commitment to develop a personal plan that can lead to a successful career while helping others. It can lead to a strong sense of fulfillment in your life.

[1] Celebritize Yourself, Author: Marsha Friedman, ISBN: 978-1-886057-20-3, Warren Publishing, Inc 2009

Steve Blash is an experienced IT professional consultant providing business and technology leadership, mentoring and vision. His areas of experience include project management, I.T. management, business process improvement, business analysis, business intelligence, data analytics and data warehousing.