Tag: Enterprise

The Transformational Enterprise Business Analyst

Written by Kathleen B. Hass, PMP on September 25, 2015. Posted in Articles.

Why do we keep talking about the Enterprise Business Analyst (EBA)? Because it is quickly becoming the pivotal business/technology role of the future. The EBA is a business-driven strategic partner and integrator, an enabler of organizational change, and the driver of business success. As a strategic partner, the EBA often becomes an internal consultant – a business relationship manager at the top of the food chain of the BA profession.

Operating at the enterprise, strategic level, the EBA engages in radical collaboration, as the Stanford University Design School refers to it. The EBA understands that today’s complex projects demand an unprecedented amount of teamwork and cooperation among all key business and technology roles in a critical project. Indeed, shared project leadership is replacing old project management models. Perhaps the most valuable partnership when operating at the enterprise level is the one between the project manager and the business analyst.

The BA and PM work together to ensure projects are launched to bring about innovative solutions, value to the customer, and wealth to the bottom line. All decisions are made with the customer in mind. Changes that add value are not only welcomed but sought after.

THE RISE OF THE ENTERPRISE BUSINESS ANALYST

The rise of the EBA marks a significant departure from business-as-usual business analysis. The EBA is a strategic asset to decompose strategy into valuable change initiatives. The EBA plugs the gap conducting the burden of analysis that is too often missing from business/technology project prioritization and selection.

EBAs work up front and personal, in support of an investment framework based on business value. The EBA performs the due diligence that is so often missing during project initiation. This due diligence includes competitive analysis, problem/opportunity analysis, experimentation, creative brainstorming, early complexity assessment, and captures the results in the form of a business case to propose a new change initiative.

TRANSFORMATIONAL PRACTICES

The EBA employs transformational practices to bring about value-based decision making and project management practices.

TRANSFORMATIONAL ROLES

The EBA fulfills many strategic roles, essentially putting a finger in the dike for many areas that have been woefully inadequate in organizations today, from business relationship manager to internal strategic consultant.

Business Relationship Manager and Internal Consultant

As business relationship manager, EBAs fully understand the needs of the business, from vision and strategy to execution of operations. EBAs build executive level relationships as well as relationships with lower level managers and practitioners. They decompose strategy into valuable projects and programs. They lead creativity sessions to ensure we conceive the most innovative solutions. They create business cases to propose new initiatives. They conduct competitive analysis to understand where their industry is headed. They coach project teams to ensure the teams understand the business need and the value expected from the initiative.

Strategist

The EBA often has a seat at the table with the executive management team, participating in strategy sessions, facilitating the management team through problem analysis, alternative analysis, and opportunity analysis.

Innovator, Designer, and Architect

The EBA understands that creativity is a skill that can be learned. Understanding and using design principles enable EBAs to lead sessions to design the transformation prior to examining alternative solutions. Using architectural techniques, the EBA makes the future visible through models and rich pictures.

Business/Technology Optimizer

World-class EBAs stay ahead of trends within business analysis, technology-enabled business practices, and in the industry of their choosing. However, staying up with trends is a difficult undertaking because of the amount of information that is out there; it is voluminous and can be overwhelming. The trick is to concentrate on keeping abreast of business and technology trends at a high level, and go deep in a just-in-time learning manner. That is educate yourself on areas of interest at the time when you need to apply them to your current endeavors.

The EBA thinks holistically about the business, the ecosystem surrounding the business, and about the technology supporting the business. The EBA understands where the industry is headed globally, and how that will impact their organization. In addition, effective EBAs understand the current technology infrastructure, and trends that are emerging. Some of the contemporary areas of focus include:

Collaboration and productivity
Customer & operations support
Cyber Security
Digital, wireless, and mobile spheres
Software
Open technology
Internet of things
Compute
Networks
Social media

Leader, not Manager

In performing all of these roles, the EBA becomes a value-driven strategic resource for the organization. The EBA has mature influence skills, collaborating with project managers and other key change agents. The EBA understands how to build and sustain high-performing teams. In a given week, the EBA might serve as:

Strategy and Competitive Analyst
Strategy Executor
Value/Benefits Manager
Creativity and Innovation Enabler
Transformational Designer
Cultural Change Manager
Team Leader

Lead through Connections

The world is hyper-connected. EBAs leverage the collective intelligence that resides in the untapped knowledge of their network. EBAs can embrace the dynamic tension between creative disruption and operational efficiency. EBAs cultivate organizational creativity in an age of complexity.

TRANSFORMATIONAL PROJECT SUCCESS MODEL

The traditional measures of project success have been on time, cost, and scope. Even with advances in technology and the project management and business analysis professions, superior project performance remains elusive. The CHAOS Manifesto 2013 reveals that 61% of IT-enabled business projects continue to fail to meet project cost, schedule, and scope goals.

In the 21st century we need to achieve 90% of projects on time, cost and scope through smaller, incremental development of solutions. And at the same time, our focus needs to be on innovation and value. Companies that fail to innovate will get lost in the dust of agile, fast-moving competitors. So, our new project success model needs to look something like this:

Clearly, the business analysis profession needs to step up to the plate to close the gap in project performance, and the EBA is emerging as that transformational role. EBAs are drastically changing the way we manage projects. EBAs adopt a more holistic view of change initiatives so that we:

Focus on delivery of business value and innovation vs. requirements management,
View change initiatives holistically, understanding that critical projects will likely impact the entire business ecosystem of people, process, organizations, rules, data, applications, and technology
Embrace architecture and design to help temper complexity and uncertainty, and
Strike a balance between analysis and intuition, order, and disruptive change.

Look for us at the Building Business Capability Conference in Las Vegas in November.

ⁱ Leading Through Connections, Insights from the 2012 IBM Global CEO Study (www.ibm.com/services/us/en/c-suite/ceostudy2012/‎
ⁱⁱ THE STANDISH GROUP, “CHAOS MANIFESTO: THINK BIG, ACT SMALL,” 2013. ONLINE AT versionone.com/assets/img/files/ChaosManifesto2013.pdf‎ (accessed January 2014).

The Business Analyst’s Accountability in Scope Creep and Changing Requirements

Written by Angela Wick on August 17, 2015. Posted in Articles. 1 Comment on The Business Analyst’s Accountability in Scope Creep and Changing Requirements

In my classes and consulting work I get the same complaints when I ask teams about the biggest roadblocks in requirements work:

“My stakeholders keep adding features.”
“My stakeholders keep changing the requirements.”
“My stakeholders don’t know what they want.”

BAs, PMs, and even developers point frustrated fingers at stakeholders who constantly add or change requirements, priorities, features, and needs. They quickly cast blame on stakeholders who don’t really know what they want and can’t define and protect the boundaries of the project: the impulsive sponsor, assuming business manager, the indecisive subject matter expert, the ambiguous architect or the distracted CIO.

Who’s the worst offender? Who’s the biggest scope creep on your projects? Well, I am sad to say, it might be you!

No matter if you work on traditional or Agile projects, your role is to facilitate the discovery of requirements, with an approach that assumes your stakeholders do not know what they want or need. Your role is to help them figure that out. Scope creep and requirements changes often come from a lack of discovery and analysis of the originally stated requirements.

If your role includes requirements elicitation and requirements management, you may need to step back and take a long, hard look at your mindset when working with stakeholders. If your stakeholders seem confused, frustrated, indecisive, bored, unavailable, demanding, then you might be the root cause of the scope creep problem!

Do you expect your stakeholders to know their requirements? Do you expect them to know all the details, data, rules, processes, people, and systems impacted? Do you expect them to tell you all of this in an organized manner? Stakeholders have ideas visions, pain points, and needs. It is up to us as BAs to help them express and discover how it all comes together as part of a solution.

BAs and PMs often blame stakeholders for constant changes in scope and requirements when the true fault often lies in the quality of the requirements processes, tasks, and techniques. The quality of how well we elicit and draw out the very details and requirements, the quality of the dialogue and analysis we stimulate in stakeholders, the team, and ourselves later becomes scope creep and change if we do not draw out the requirements that creep up on us later.

In Agile projects, we elicit requirements based on value management principles and priorities rather than scope management. Value management principles are similar in that we need to constantly facilitate what features add the most value to the organization and prioritize the backlog accordingly. Scope management, when done well, also facilitates value management by ensuring we have analyzed and elicited requirements of the most value to the organization. These are often assumed and unstated requirements of our stakeholders.

We need to change our perspective and approach requirements differently. We need to approach requirements as a learning and discovery process. We need to help our teams uncover, discover and model scope. We need to develop and maintain our team’s shared understanding of scope, vision, and priorities throughout the project.

I see two types of scope creep and requirements change:

Something external or internal to the project changes and it impacts the scope and requirements of the project and/or solution
Requirements and scope are discovered as stakeholders and project team members evolve their thoughts and work together to uncover the details and impacts of the solution.

The first one is common to all projects, regardless if they are agile or traditional and we need to be ready for changes. The second type is where we can influence things dramatically as BAs.

How can you do your part to prevent scope creep and create shared understanding?

1. Check in with yourself on mindset: Are you approaching the requirements process expecting your stakeholders to tell you what they want? Or are you approaching it with a mindset that you are a facilitator of discovery? Don’t gather, elicit. There are always exceptions, but most scope creep and requirement changes are due to a “gathering” mentality instead of an “elicitation” mentality.

When a BA “gathers” requirements it implies a passive approach where stakeholders spoon-feed requirements to the BA. This passive approach, which does not include any analysis, leads to many missed requirements and fluctuations in scope.

When we “elicit” requirements, we iteratively extract and analyze stakeholder knowledge. We use probing and high impact questions and interactive elicitation techniques to help stakeholders discover and explore requirements. We use facilitation skills that promote meaningful dialogue and inspire active collaboration. Strategic elicitation minimizes scope creep by helping teams uncover assumptions, risks, and constraints.

2. Customize Your Approach. Do not assume you can use the same techniques for every project! This assumption will eventually lead to scope creep, erratic requirements, rework, defects and failed projects. Instead, be thoughtful in planning the requirements approach for your project. Every project is different. Every stakeholder group is different. Plan your approach based on what you know at the beginning of the project and refine the approach as you go.

Use powerful techniques to engage stakeholders and get them talking about the solution in ways that bring out more impacts, angles, and details. Techniques like collaborative games, prototyping, creative facilitation, and bringing analysis frameworks into facilitated sessions to bring out engaging dialogue.

Use techniques that create a framework for dialog that help stakeholders fill in the pieces that they would not have known to tell you. Techniques like Process Modeling, SIPOC, Business Model Canvas, Business Rules analysis, User Story Mapping, to name a few.

3. Focus on the Why and the Value. One of the best ways to start your scope management process is to help your team define WHY:

What problem is your team trying to solve?
What need are you trying to fulfill?
• What opportunity are you trying to exploit?
• Why are the stated requirements important to the stakeholder?

Once you create a shared understanding of why, then maintain it and use it to focus your stakeholders when defining the value the requirements bring.

4. Find the Gaps. There are always gaps! Why? Well, it’s the nature of project work. You just can’t know everything at the beginning—so keep your eyes open and help your team find the gaps. As a project evolves, gaps appear in many shapes and sizes, so challenge your team to find/uncover/unearth all: stakeholders, dependencies, constraints, assumptions, systems, processes, end users, personas, etc.

Warning: Don’t expect to locate all gaps in one big brainstorming effort at the beginning of the project. We need to approach requirements as a learning and discovery process. The discovery is iterative—it evolves over time. Be sure to systematically analyze, integrate and share each new piece that lands in the puzzle.

5. Draw Pictures. Visual models are often the best way to get conversations started and highlight gaps in shared understanding. Pictures prevent scope creep and missed requirements by providing context for discussions. They illuminate gaps and assumptions in ways that words/text can’t. Pictures also improve engagement and interaction by moving multitasking eyes away from other distractions and devices.

You can create pictures by gathering information from stakeholders one-on-one before a large group session or you can use facilitation techniques that help stakeholder groups create pictures for you. Just present a basic model or informal drawing and let the stakeholders react and learn and then update the model collaboratively.

6. Let people think. You can’t expect to hammer out solid, complete, stable requirements in a single session. Even if the session is a full day or a full week, you will miss requirements and/or you will miscalculate user needs if you do not give yourself and others time to step away and think.

Your team will make better decisions and will be able to more clearly define what they want if they get time to reflect in between elicitation sessions. They will be able to share information with their team, bounce ideas off others, and evaluate ideas in the context of their daily work, rather than being sequestered in a marathon, one-and-done workshop.

This iterative elicit and analyze approach also gives BAs the time they need to evaluate stakeholder input and refine the requirements approach as the project evolves:

7. Expect Change. Here’s the bad news…change happens! Even teams with awesome collaboration, expertise and shared understanding will experience changes in requirements and scope. So, plan for it! Change will be less disruptive if it’s an expected and accepted part of your approach.
BAs need to accept at least partial responsibility for scope creep and requirement changes. The quality of a BA’s elicitation, facilitation, modelling and analysis skills has a significant impact on the project. BAs who strategically engage stakeholders to create meaningful collaboration and shared understanding will experience significantly less scope creep, requirements changes, defects and rework.

An Approach to Requirements Elaboration in an Agile Environment

Written by Aditi Sharma on August 17, 2015. Posted in Articles.

Requirements gathering is the cornerstone to the success of any Agile project. There is no denying the fact that stakeholders often struggle in providing the functions and features that they expect from a system but rather provide the details and system behaviour. The key to achieving clarity is progressive elaboration. Interviews and workshops with stakeholders conducted by the business analyst can achieve this progressive elaboration.

Agile projects often use user stories, which act as the starting point for further refinement in terms of requirements elaboration, design, risks, and costs. User stories are usually captured using informal techniques and as such are not available to all the team members until it is segregated and scaled to fit in traceable stories. The use of informal techniques suggests the need for an elicitation process and a supporting tool that helps to share the artefacts as and when they are created, reviewed and approved.

Most organizations would need to invest in tools to support the Agile way of working. To be effective, the tools should be used to create a virtual platform to connect teams to each other. They can then use the tools to share information, keep it up-to-date, track and review information packets, and to keep the momentum of the project without losing focus and pace of deliverables. Utilizing this tool leads to real-time sharing of information and better transparency and visibility of workloads and ultimately, of the schedule.

If teams adopt the above-mentioned way of working then a few potential issues get addressed early in the project lifecycle. These include issues like blocked information flow, use of old and redundant information, the blurred view of work items, and low traceability. Addressing these issues mitigates a lot of problems with which a business analyst (and other team members) may struggle. However, to address this completely from the business requirements point of view, the base has to be laid out properly and completely. This need puts requirements elicitation and elaboration in the spotlight.

As mentioned, requirements elicitation often starts in the form of user stories. At this level, it is comparable to an outline of the expectations from the system in terms of functions and features. Once the outline of expectations is created and agreed with stakeholders, the focus should quickly move to the elaboration activity. The extent to which detailing is required varies depending on the team’s needs, however, this elaboration activity must achieve complete and correct documentation of business requirements, design, its rationale, and traceability (since if a task does not trace back to a user story, then it is not required).

However, the requirements elaboration activity is easier said than done. Depending on the stakeholders involved, different tools and techniques may have to be applied. Unlike in a traditional project where the requirements elaboration phase consists of detailed analysis and complete specification document, in Agile, this is done differently. The requirements elaboration phase of an Agile project focuses on identifying the user stories first, then detailing them as the project moves ahead. Essentially, the elaboration activity initially concentrates on high priority features and then progressively incorporates details. Storyboards and prototypes are powerful ways to gather feedback and quickly incorporate it. Allowing users to see details early on reduces rework costs since integration with other systems has not yet been done.

Since further iterations of elaboration build on user stories, the business analyst should ensure that certain key information points are captured upfront while creating the user story, avoiding the need to re-visit these stories later. Key information includes actors, pre-conditions, triggers, benefit, acceptance criteria and if possible, non-functional requirements. Ensuring the capture of these data points early in the phase helps build the understanding of the requirements and avoids the pitfalls that transform simple oversights into multiple issues at a later point in time. This data capture also allows the business analyst to start documenting the requirements using formal techniques and begin creating a document for review, sign-off and trace.

Another buzzword that comes up is “collaboration”. To understand this, think of scenarios where the business owner will probably provide his expectations on the system behaviour but leave the system design considerations to the technical teams. Collaboration is the essential thread connecting these teams. Any one team working in a silo is a recipe for disaster; we need open communication channels leading to high levels of trust. The need for collaboration needs to be factored in by the business analyst. Note that requirements documentation may take any form – spreadsheets, documents, presentations, diagrams, use cases. The driving force here is not the format, but the content (what), context (when, where), and collaboration amongst different teams say, IT & Business Analyst and Business Analyst & Development team.

It may also help to elicit, elaborate, and segregate the “must have” requirements from “good to have” requirements early on. This information can be used for prioritizing in sprints considering business user needs and value, and from change management point of view. Readily available information translates to quicker turnaround times for next actions or decisions.

Being Agile during the requirements process allows projects to develop more efficiently by having work tracks running in parallel rather than waiting for fully developed requirements that may have little interaction with business and little opportunities for mid-course corrections. There are heaps of benefits compared to the traditional Waterfall way of requirement elicitation and elaboration. This definitely marks a big change in the way solutions are designed and delivered in shorter time frames by various organizations.

The Future is Now: The 21st Century Enterprise Business Analyst

Written by Kathleen B. Hass, PMP on June 29, 2015. Posted in Articles. 1 Comment on The Future is Now: The 21st Century Enterprise Business Analyst

INTRODUCTION

Business analysis is a relatively new profession. Some say it is not really a profession, but more of a line of work or collection of activities. Others say it is a discipline, a business practice that has been woefully absent in the complex world of business. The International Institute of Business Analysis defines business analysis as follows:

…the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.

Business analysis is performed on a variety of initiatives within an enterprise. Initiatives may be strategic, tactical, or operational. Business analysis may be performed within the boundaries of a project or throughout enterprise evolution and continuous improvement. It can be used to understand the current state, to define the future state, and to determine the activities required to move from the current to the future stateⁱ.

THE BUSINESS ANALYSIS JOURNEY

20th-century business analysis has been a mostly tactical endeavor, focusing on requirements definition and management. According to anecdotal evidence I have collected over the last few years, the BA activities have been distributed something like this:

Notice the image of a baby at the center. This is intentional, and represents the early stages of business analysis. But we need to grow up fast to meet the challenges of the 21st century. While some work at the strategic level, the focus of the vast majority of the BA practitioners has been mostly:

Management vs. leadership
Tactical orientation vs. systems thinking
Project and requirements management vs. complexity management
Linear vs. adaptive
Business as usual vs. innovation
Project outcomes vs. business/customer value

But, the 21st century challenges us to change the way we initiate and manage change in our organizations. Traditional jobs are changing. BAs are focusing on strategy, innovation, value vs. requirements management. Project managers are focusing on complexity management vs. project management.

Organizations cannot find the talent they need to negotiate the constant change and unrelenting complexities of the 21st century. They need critical thinkers with the ability to adapt, invent, and reinvent. Collaborate, create, and innovate. Understand and leverage the complexities to harness creativity.

To remain competitive in these challenging times, CIOs realize the BA role is at the heart of future success. CIOs appreciate that BAs are in demand and will play a critical role in the future, but not the type of BAs we have today. And so, they are rebuilding the BA role. CIOs around the globe are searching their resources to find experienced and solutions focused IT and business professionals who are ready and willing to step into the leadership role of the Enterprise Business Analyst, moving from a requirements focus to a strategic solution focusⁱⁱ.

THE RISE OF THE ENTERPRISE BUSINESS ANALYSIS PRACTICE – IT’S ALL ABOUT VALUE

Business analysis is transforming itself before our very eyes to create better business outcomes. Some refer to it as ‘Breakthrough Business Analysis.’ The role of the enterprise business analyst (EBA) is coming into its own. The focus is clear: it’s all about value.

While not all change initiatives are complex, it is clear that the world is changing rapidly, technology advances are fast and furious, and businesses need to ‘innovate or evaporate.’ If we are not bringing about value, we should question the need for the initiative. So, what does breakthrough value-based business analysis look like?

While moderately complex projects will still need traditional BA practices focusing on requirements definition and management, these will become fewer and fewer as we transgress through the 21st century. Traditional BA practices work when not dealing with complexity, but are deficient when managing complex enterprise change initiatives.

Enterprise business analysis focuses on delivery of business value and innovation. EBAs understand the holistic nature of change; transformational change requires attention to people, process, organizations, rules, data, applications, and technologies to make up a transformational business practice. The EBA embraces business architecture and deliberate design to help temper project failure.

Realizing that a holistic view of change is both an art and a science, EBAs strike a balance between analysis and intuition, and order and disruptive change. Decision making is collaborative. Thinking is global, holistic, strategic. Complexity is leveraged to achieve creativity. Leadership is shared, diverse, expert. Teams are collaborative and high performing. Methods are adaptive, creative, agile, visual. Solutions are innovative, competitive, and sometimes unsettling and disruptive. Value is delivered early and often.

Breakthrough business analysis produces groundbreaking results. It requires different thinking and new practices and systemsⁱⁱⁱ.

THE ENTERPRISE BUSINESS ANALYST – A COMPLEX ROLE

One of the reasons the role and capabilities of the business analyst is difficult to describe is that it is a very complex function with many variants. The Generalist EBA wears many hats, from strategy analyst to business relationship manager. Whereas the specialist EBA may focus on business architecture or business rules management. At the same time, EBAs are often business domain experts so that they understand and are authorities in both the business domain and the technology supporting the business. Mostly all EBAs focus on business/technology optimization, staying current on the latest technological advances and incorporating them into the IT suite of offerings.

The next article will delve deeper into the various aspects of the EBA, describing the:

Nature of the EBA role
Value of the EBA role
Special skills needed to perform the EBA role.

Don’t forget to leave your comments below.

References

i A Guide to the Business Analysis Body of Knowledge® v3, International Institute of Business Analysis, 2015
ii Mark McDonald, Ph.D., former group vice president and head of research in Gartner Executive Programs
http://blogs.gartner.com/mark_mcdonald/2012/01/30/amplifying-the-role-of-the-business-analyst/
iii Better, Smarter, Faster: Accelerating Innovation Across the Enterprise, 2013, Jama Software, Inc.

Verify, Validate, De-Vaticanate. The Pope as Change Agent

Written by Marcos Ferrer on March 2, 2015. Posted in Articles.

Who’d of thunk it? The Pope’s New Year speech offers insight into issues that affect MANY organizations. This courageous leader gave a list of fifteen sicknesses inflicting the Vatican organization.

This month I picked a few of these Vatican issues to discuss. I chose those that resonate loudest with the challenges facing transformational leaders working with “entrenched” dysfunctions. When such leaders clear the way, business analysis can help. Without such leadership, business analysis can only reveal what is “sick”, with no power to “heal.

To help relate the very Catholic analysis to secular organizations I have inserted suggested “secular” word changes in angle brackets .

How many of these are impacting your ability to perform the BA role? How many of these are “sins” of your own?

Pope says beware of:

The sickness of feeling oneself “immortal,” “immune” or in fact “indispensable,” neglecting the necessary and usual controls. A Curia that does not criticize itself, which does not update itself, which does not seek to improve itself is a sick body…It is the sickness… also of those who transform themselves into bosses and feel themselves superior to all and not at the service of all.

As BAs we must be aware of the “requirements risk” of trying to satisfy stakeholders when business leadership is too busy, too important or too judgmental to participate. There are no business needs where leadership is missing or (worse) serving itself instead of the common good. Such environments will tend to focus on stakeholder wants.

Analysis becomes politi-technical (“can we make what the most powerful stakeholders want and not be blamed by the others?”). Business Analysis (“can we advance business goals and objectives with solution changes”) is no longer in play as a guiding pattern.

This is OK if we are changing systems that already serve our mission and need minor improvements. It is not OK when enterprise level transformations are in play. Consider the difference between the following two exchanges:

Exchange 1 (small):

Stakeholder: I want to have ice cream anywhere all the time.
Analyst: Here is a little ice cream that IT made just for us.
Stakeholder: Nice.

Exchange 2 (enterprise):

Stakeholder: I want everyone to eat ice cream everywhere all the time.
Analyst: Here is a little ice cream that IT made to help users imagine the actual dessert that would work for them.
Stakeholder: We can’t let them try it – they will just complain. Give me that serving of ice cream to critique, and then I expect you to produce the rest ASAP.
Analyst: Not so nice.

Pope’s antidote:

The antidote to this epidemic is the grace to see ourselves as sinners and to say with all our heart: “We are unworthy servants; we have only done what was our duty” <”please work with us to be better”> (Luke 17:10).

BABOK antidote:

Step up and “serve from behind”. If there is NO leadership at all (rare, but some “leaders” will command a project then disappear) then just pick up a broom and try to clear some space for a meeting. If there is little or no leadership from above (more common) then do your best to analyze and represent the wants expressed – to communicate IS our duty.

Pope says beware of:

…The sickness of mental and spiritual “petrification (sic)”: namely those who have a heart of stone and a “stiff-neck” (Acts 7:51-60); those that, along the way, lose interior serenity, vivacity and daring and hide themselves under papers becoming “practice machines” and not “men of God” (Cf. Hebrews 3:12).

As BAs we must be aware that physical cogs cannot change (design changes, cogs follow), and humans that have found cog-hood don’t want to change. BABOK 1.6 listed “Sales” as a key BA skill. BABOK 2.0 dropped “Sales” in favor of influencing. Same thing.

Pope’s antidote:

“Don’t be petrified, ask Jesus to help un-petrify yourself” and/or “you are fired” (I am guessing, Francis didn’t say).

BABOK antidote:

If you are not practicing sales skills you should practice ducking and bobbing. Try to help stakeholders find “what is in it for them” if they want anything at all. If you are really good at sales you can earn a lot more in sales (or as CEO) instead of as BA. BABOK is at a disadvantage to Jesus, who could move people with pure love and miracles, at least in His domain. IT projects; I am not so sure WWJD.

There is more from Francis, but not this month. What spirituality helps get you through your BA? Let us know in the comments below.

Have fun, try to laugh and remember – the Pope needs BAs too 🙂

Don’t forget to leave your comments below.