October 2007 - The FoCuSeD™ Facilitator eNewsletter

Should a Project Manager BE a Facilitator? | Gary Rush Facilitation

Coming from an IT background, as a Business Analyst, Programmer, and Project Manager, I learned that Project Managers managed content. Therefore, a Project Manager could not be a Facilitator – it violated neutrality. But, with the growth of Project Management, thanks to the Project Management Institute (PMI), and the growth of Project Management Offices (PMOs), that has changed my view.

PMI publishes a handbook for Project Managers – the Project Management Body of Knowledge (PMBoK). It describes project management independently of what type of project is being managed and independent of what type of business the project is for. In other words, project management is project management – whether it’s for IT, construction, marketing, or whatever.

I watched a company implement a PMO in which the Project Managers managed all types of projects, from IT to construction to facility design. These Project Managers were all trained as Facilitators. So, why can’t a Project Manager BE a Facilitator?

Facilitator

The Facilitator defines a process for a group of people that enables them to accomplish a task. The Facilitator then guides the group through the process to accomplish their task. Effective Facilitators are able to guide the group through its stages of development managing the emotional growth. All Facilitators must be content neutral – that is, they must not engage in or bring in information or opinions regarding the subject matter or business being discussed. They do however, through preparation, provide effective processes for a group to follow. The effective processes brought by the Facilitator focus the content knowledge brought by the group, enabling effective decision-making. Facilitators are process experts.

Project Manager

According to the PMBoK, “Project management is accomplished through the application and integration of the project management processes of initiating, planning, executing, monitoring and controlling, and closing. The Project Manager is the person responsible for accomplishing the project objectives. Managing a project includes:

• Identifying requirements.
• Establishing clear and achievable objectives.
• Balancing competing demands for quality, scope, time, and cost.
• Adapting the specification, plans, and approaches to the different concerns and expectations of stakeholders.”

Looking at the definition from the PMBoK above, the Project Manager is an expert on the process of Project Management. It doesn’t state that they are content experts.

Rethinking the Role

Given the role-descriptions above, we need to rethink the traditional view of the role of the Project Manager. Project Managers are process experts – expert in the project management process. Facilitators are process experts – experts in the Facilitation process. Both are more knowledgeable about process than about content. How many Project Managers know as much about a particular business as their clients do? If project management is project management regardless of the type of project, why do we ask Project Managers to know about content? Project Managers are only successful if they are able to form their teams and get them to accomplish their task – just as a Facilitator.

Project Managers in the 21st Century

Since companies first started using Information Technology, they insisted that Project Managers know business content. That isn’t true anymore. Project Managers should remain content neutral. By remaining neutral, they:

• Find the appropriate clients who know the business content – this provides more effective information.
• Focus on process and don’t influence content directions – this provides higher quality outcome.

Project Managers should facilitate the development of project plans, the identification of requirements, the establishment of objectives, and every other aspect of a project. In the implementation of the PMO mentioned earlier, all Project Managers were trained as Facilitators. Why not? Properly facilitated projects using the proper process produces better results that have the support of all stakeholders and have the greatest chance of success.

Benefits

By training Project Managers to be Facilitators and define their role as a Project Manager/ Facilitator, we gain the following benefits:

• Project Managers learn skills to bring groups together to develop consensus and support.
• Project Managers focus on the right processes to:
  
  
  • Identify requirements of the client.
  • Establish clear and achievable objectives for the project.
  • Balance competing demands for quality, scope, time, and cost by involving the appropriate parties.
  • Inclusively adapt the specification, plans, and approaches to the different concerns and expectations of stakeholders.

Conclusion

A Project Manager should BE a Facilitator.

“Be a Leader – Great Leaders are Facilitators.”

Why Can't a Business Analyst be Facilitative? | Gary Rush Facilitation

Introduction

Coming from an IT background, as a Business Analyst, Programmer, and Project Manager, I learned that the role of a Business Analyst was to understand both process and content. Business Analysts defined the requirements process, had to fully understand the business, gather requirements from the business stakeholder, and often made scope decisions – therefore, a Business Analyst could not be a Facilitator, the role violated neutrality. But, with the growth of Business Analysis, thanks to the International Institute of Business Analysis (IIBA), I have changed my view. “Why can’t a Business Analyst be Facilitative?” Business Analysts are more successful if they are able to guide their group through a facilitated process to accomplish their task. They produce better results that have the buy-in of all stakeholders enabling the greatest chance of success. Note: Effective group facilitation requires a Facilitator / Session Leader who knows both People and Process skills – “Structured Facilitation.”

International Institute of Business Analysis’ (IIBA’s) handbook for Business Analysts – A Guide to the Business Analysis Body of Knowledge (BABOK®) describes business analysis independently of what type of business the project is for. In other words, business analysis is business analysis – whether it’s for insurance, construction, marketing, or any other business.

Facilitator Role versus Business Analyst Role

Facilitator Role

“A Facilitator is a content neutral task-leader who forms a group of people into a collaborative team supporting consensus and uses a range of processes to enable the group to accomplish their task. The Facilitator is responsible for the context.” (Rush, 2013)

Looking at the definition, a Facilitator defines a process for a group that enables them to accomplish a task and then guides the group through the process to accomplish their task.

Effective Facilitators are able to seamlessly integrate the process to accomplish a task along with the emotional group cycle while considering the people’s characteristics. Facilitators are content neutral – that is, they must not contribute information or opinions regarding the subject matter or business being discussed. They do however, through preparation, provide effective processes for a group to follow. The effective processes brought by the Facilitator focuses the content knowledge brought by the group, enabling effective decision-making.

Facilitators are process experts – experts in the facilitation process.

Business Analyst Role

According to the BABOK® (IIBA version 2.0), “Business Analysis is the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.”

Looking at the definition, Business Analysts are process experts – experts in analysis and requirements definition making them responsible for the context. It doesn’t state that they have to be content experts.

Rethinking the Role – The Facilitative Business Analyst

What’s required to do business analysis, as described, leads me to rethink the role and believe that a Business Analyst who uses facilitation skills and facilitates requirements can focus on the analysis process and be more effective.

Let’s look at the similarities between them:

• Facilitators are process experts – experts in the Facilitation process.
• Business Analysts are process experts – experts in analysis and requirements definition.
• Both are more knowledgeable about process than about content – they are content neutral.

Business Analysts gather requirements and analyze business and if analysis is analysis regardless of the type of business, then we can redefine the traditional view of the role of the Business Analyst.

Facilitative Business Analyst Core Competencies

To begin, let’s start with the IAF Core Facilitator Competencies (IAF, 2003):

• Create Collaborative Client Relationships.
• Plan Appropriate Group Processes.
• Create and Sustain a Participatory Environment.
• Guide Group to Appropriate and Useful Outcomes.
• Build and Maintain Professional Knowledge.
• Model Positive Professional Attitude.

Given that the two roles are similar, we can apply these core competencies to a Business Analyst as follows:

1. Create Collaborative Client Relationships.

Facilitator: This addresses the Facilitator’s relationship with the client. Does the Facilitator prepare properly by interviewing the client to define commitment, roles, and outcome?

Business Analyst: The Business Analyst must develop a collaborative relationship with their stakeholders to ensure the requirements meet their needs. They identify the appropriate stakeholders who know the business content providing effective information and requirements. This keeps the decision-making for scope, budget, and schedule with the stakeholders. Business Analysts prepare by interviewing their stakeholders to ensure that the business is well understood and the requirements meet their needs. This establishes a collaborative relationship.

2. Plan Appropriate Group/Analysis Processes.

Facilitator: This addresses the Facilitator’s ability to design and select the right processes and tools that deliver the desired outcome while supporting a diverse group of people, characteristics, and thinking styles to reach consensus.

Business Analyst: The Business Analyst needs to design and select the right processes and tools that deliver the desired requirements while supporting a diverse group of people, their characteristics, and thinking styles. Their knowledge of analysis defines the processes they follow. Facilitating stakeholders to develop the requirements gains ownership and buy-in. This buy-in makes the objectives achievable and clear because they were developed by and for the stakeholders.

3. Create and Sustain a Participatory Environment.

Facilitator: This addresses the ability of the Facilitator to manage communication, manage conflict, enable creativity, and encourage participation.

Business Analyst: The Business Analyst must manage communication, manage conflict, enable creativity, and encourage participation. Business Analysts must know “how to” actively listen, enable creativity, and manage conflict all while ensuring that everyone has an equal opportunity to participate. This develops better ideas from a more involved set of stakeholders and shares responsibility for success. Note: Understanding how groups evolve (Tuckman, 1965), how diversity impacts groups, and how people think and learn are important to creating and sustaining a participatory environment.

4. Guide Group/Project to Appropriate and Useful Outcomes.

Facilitator: This addresses the Facilitator’s ability to execute the designed processes, guide the group, stay on track, and achieve the desired outcome.

Business Analyst: The Business Analyst needs to execute the selected processes by guiding the group ensuring that barriers are removed. This enables and pushes the stakeholders to make content decisions, e.g., scope, time, cost, quality, and priorities providing more ownership, higher quality, and more agility in adapting the specifications, plans, and approaches. These are the skills related to the Business Analyst’s ability to execute the processes or adjust as needed in support of stakeholders. Note: Effective Business Analysts guide others ensuring that barriers are removed so that the stakeholders are able to effectively define their requirements.

5. Build and Maintain Professional Knowledge.

Facilitator: The Facilitator continues to be part of the profession and continues to learn new concepts and ideas.

Business Analyst: The Business Analyst must maintain professional knowledge through continuing education. They continue to learn new concepts of analysis, new processes, new concepts to engage stakeholders, and “how to” manage group dynamics. Business Analysts who use only one method become stagnant – they need to continue learning.

6. Model Positive Professional Attitude.

Facilitator: This addresses the Facilitator’s ability to remain neutral, act with integrity, and be self-aware.

Business Analyst: The Business Analyst must manage analysis, act with integrity, and be self-aware. They make facilitative business analysis contagious because they model what they practice. They set the tone.

These six competencies define the “Facilitative Business Analyst Core Competencies”.

The Mandala of the Facilitative Business Analyst

The Facilitative Business Analyst is a combination of his or her capabilities, personality, and beliefs – “The Self”. When Business Analysts practice Facilitative Business Analysis, they support their core competencies to achieve their project vision with: knowledge – being informed and prepared, actively listening to all stakeholders and enabling them to listen to each other, believing in the wisdom of the stakeholders and process creating a respectful, participatory environment.

The Facilitative Business Analyst is more flexible and agile in moving from one project to another because he or she, as a process expert, does not need to know the content. The Facilitative Business Analyst builds an effective relationship with stakeholders who:

• Know the business content.
• Bring content knowledge needed for the specific project.
• Work as a collaborative team.
• Take ownership of their requirements.

Making it Work

Creating Facilitative Business Analysis requires a change in how organizations view and train Business Analysts. Responsibility for the quality of requirements rests with all of the stakeholders. Organizations need to emphasize this.

Creating an environment that enables Facilitative Business Analysis requires:

• Business Analysts to be trained in effective Business Analysis skills. (The most effective way to do this is through training that enables a Business Analyst to become a Certified Business Analysis Professional (CBAP)).
• Business Analysts to be trained in effective Facilitation skills. (The most effective way to do this is through facilitation training to become an IAF Certified™ Professional Facilitator (CPF).)
• Redefining the role to focus on process so that responsibility is shared across all stakeholders – Facilitative Business Analysts are responsible for the analysis process and stakeholders are responsible for requirements quality.
• Involving stakeholders in all aspects of requirements definition so that stakeholders are making content decisions guided by the Facilitative Business Analyst.

By redefining the Business Analyst’s role as a Facilitative Business Analyst, the organization gains:

• Facilitative Business Analysts who are skilled at bringing stakeholders together to develop consensus and buy-in. Requirements are more successful as a result.
• Facilitative Business Analysts who focus on the right processes to:
  • Identify requirements of the stakeholders.
  • Establish clear and achievable objectives.
  • Balance competing demands for quality, scope, time, and cost by involving the appropriate stakeholders.
  • Inclusively adapt the requirements to the needs of the stakeholders.

Conclusion

Facilitative Business Analysts produce better results that have the buy-in of all stakeholders enabling the greatest chance of success.

"A Business Analyst should BE a Facilitative Business Analyst"

References

• International Association of Facilitators (IAF). (2000, Winter) "Facilitator Competencies". Group Facilitation: A Research and Applications Journal, Volume # 2 Number 2. Revised in February 2003.
• International Institute of Business Analysis (IIBA), A Guide to the Business Analysis Body of Knowledge (BABOK®) (IIBA Version 2.0), 2010.
• Rush, G., "Revisiting My Definition of a Facilitator", The FoCuSeD™ Facilitator eNewsletter, August 2013, Chicago, IL, MGR Consulting.
• Tuckman, B.W., “Development sequence in small groups”, Psychological Bulletin, Issue 63, pages 384-399, 1965.

Why, What, When, Who, How, and Where? by Gary Rush, IAF CPF

I’ve been in the IT industry for 40 years and I’ve watched methods come and go but it has been a lot of re-engineering of the same. From Structured Analysis, Information Engineering, Agile, etc., the IT industry has been looking for the “right” answer on “how to” develop solutions. We’ve had it all along, but we get too wrapped up in the jargon and in the latest fad. The Why, What, When, Who, How, and Where? still need to be answered to develop quality requirements. Analysis and design can answer those six questions – how you get there varies.

Analysis – Why, What, and When?

Why?

“Why?” does the business exist? Why does this process exist? These questions set the context of the work. This question is often neglected and organizations sometimes re-engineer a process that, if asked why it exists, should not exist in the first place. There are many tools to capture the answer to, “Why?”. Context Diagrams, Purpose Statements, and even a narrative answer are effective and work.

What?

“What?” is the classical “logical” analysis defined in Structured Analysis – separating “What” from “How”. What defines what must happen, what data must be captured and used, and what rules must be followed – irrespective of how it is implemented. Defining the “what” of a business is important. “What” doesn’t change often – it’s very stable. For example, what accounts payable does has been the same for decades – the change comes in “how” it is implemented. Process Models, Use Cases, Conceptual and Logical Data Models all help define “What”.

When?

“When?” is important to know when actions occur in a business or process. “When?” guides process and data needs in an organization. “When” speaks to Business Rules, Decision logic, and timing for processes. “When” doesn’t change when implemented.

Design – Who, How, and Where?

Who?

When you move into design, you are moving from a pure environment to one of reality. You first need to know “who” is involved. Who is the user? Who is the customer? These answers help define a flow and sequence of a business. We don’t talk about the “who” in analysis because it can change in implementation. Expanded Use Cases, User Stories, Dependency Diagrams, Work Flow Diagrams, all help define “Who”.

How?

Now, we need to know “how” a business or process will work in the real world – with media, exceptions, people, etc. This includes understanding the supporting technology and architecture as they directly influence “how” the process will work. Prototyping, Work Flow Diagrams, User Stories, etc., all help define “How”.

Where?

“Where?” is the place or location in which a process gets used. Will it be at a desk? Will it work in a production line? These questions help define the appropriate technology. Again, Prototyping, Work Flow Diagrams, User Stories, etc., help define “Where”.

The Biggest Problems

The biggest problems are never the methods used. The biggest problems are:

• Choosing a method that gets you suitable solutions. Too often, organizations select a method and neglect to include important elements – this has happened with Agile. They develop solutions, but skip the analysis. Quick, iterative, etc., are all great, when analysis is included, but skipping important elements is not a good strategy.
  
  
• Getting business engagement has plagued IT for decades. The solution is simple – use facilitated workshops/meetings to develop the analysis and design artifacts. It reduces time (taking 1/4th the amount of time on average), increases quality, increases engagement, and the engagement allows business to take ownership of the artifacts.

So…

Which method is best? My answer is, “The one you actually use.” Many methods help you get to a suitable solution, so pick one you are comfortable with and use it. You can manage a project using numerous strategies, Waterfall, Agile, RAD, etc., all work. Looking for the “right” method misses the point. If you can answer the Why? What? When? Who? How? and Where? questions, you have selected methods that work. Finally, use facilitated workshops/meetings to develop all of the analysis and design artifacts. My advice – Keep it simple – understand the underlying concepts and the answers become obvious.