Tag: Team

How Do You Get Team Members to Come Prepared to the Meeting?

Written by Dana Brownlee on December 14, 2010. Posted in Articles.

The Problem:

We’ve all attended meetings where participants were asked to read a document, do some research, or conduct some other “homework” prior to the meeting but very few people actually did it. Obviously, the intent of assigning the pre-work is to ensure that all attendees are prepared which should result in a quick, efficient meeting… right???? Wrong!!! Too often some attendees don’t complete the assignment as requested which drags down the entire group. Before you lead your next meeting, consider these tips about assigning pre-work.

Consider these suggestions….

Give the group a choice about how to complete the prep (either outside or within the meeting). You might say, “Everyone will need to review the requirements document prior to our review discussion. We can either do it as a group and plan to meet for a full day or everyone can review it offline, and the group will meet for 2-3 hours to discuss changes. Which approach does the group prefer?” Most groups will opt for the shorter meeting. This technique tends to work because the group was given the option to review the document during the meeting and they chose not to do that.
Assign specific team members to lead certain sections of the meeting (which would require them to have completed the pre-work). When they know they will be asked to lead discussion, attendees are much more likely to have done their homework. No one wants to appear unprepared!
Try to keep the pre-work brief. The more complicated it is, the less likely attendees are to complete it.
Ask team members to email you either a list of questions or comments on the pre-work several days prior to the meeting. This acts as a confirmation to let you know that they have indeed reviewed the document. If you don’t get feedback from someone on the team, place a call to them asap to request their feedback.
Give attendees ample time to complete the pre-work. If you ask them to review a lengthy document 3 days prior to the meeting, it may not provide ample notice. Ideally, let the team select the due date for completion of the pre-work. This buy in significantly increases the likelihood of compliance.
Discuss the issue of attendees not being prepared during the meeting debrief, and encourage the team to identify approaches to address the issue (e.g. incentives, “punishments”, etc.)

Don’t forget to leave your comments below

Dana Brownlee is President of Professionalism Matters, Inc. a boutique professional development corporate training firm. Her firm operates www.professionalismmatters.com and www.meetinggenie.com, an online resource for meeting facilitation tips, training, and instructional DVDs. Her latest publications are “Are You Running a Meeting or Drowning in Chaos?” and “5 Secrets to Virtually Cut Your Meeting Time in Half!” She can be reached at [email protected].

Interrogating the Business Analyst Process to Discover Your own Value

Written by Laura Brandenburg on September 14, 2010. Posted in Articles.

One of the ways we can unknowingly hold our careers back is failing to understand and communicate our value effectively. Many of the business analysts I work with in their job search and career development initially lack an appreciation for how they contribute to the organization’s bottom line.

There are two common challenges that I see:

Failure to understand how business analyst activities tie to clear business objectives.
Failure to fully appreciate the value of the contributions they make as individuals.

In an earlier Business Analyst Times article, “Think “I” Instead of “We” When Talking about Your BA Career,.” I’ve already touched on point #2 above. Today I’d like to discuss how an intrinsic focus on business analysis activities unframed in a business value context can be career-limiting.

In an often-quoted article from CIO.com the value of the business analyst was cast in relief:

“For two decades, the CIO has been viewed as the ultimate broker between the business and technology functions. But while that may be an accurate perception in the executive boardroom, down in the trenches, business analysts have been the ones tasked with developing business cases for IT application development, in the process smoothing relations among competing parties and moving projects along.”¹

This statement speaks to a business-focused value of the business analyst. From an executive perspective, business analysts are valued because they help contribute to successful projects that have a solid business case. They are in the trenches ensuring that IT investments create value for the business.

However, oftentimes we see and hear business analysts talking about their value in terms intrinsic to the BA process. They focus on what we do as business analysts over and above why we do it. For every what, there is a why. And one of the best things we can do for our careers is to interrogate our own process with the same rigor with which we might challenge the process our stakeholders use to complete their work.

For example, one of the guidelines for writing textual requirements from the BABOK® Guide is “using consistent technology”. This is a worthwhile attribute and we all know that any decent business analyst will use terms consistently throughout their requirements specifications. But “using consistent terminology” is an answer to “what we do” or “how we do it”. It does not answer “why do we do things this way.” Let’s interrogate our own process to discover the why:

Interrogator: How does “using consistent terminology” create value for our organization?

Business Analyst: It reduces confusion about requirements.

Interrogator: Why does that matter?

Business Analyst: Well, if stakeholders are confused about requirements, we might spend extra time validating the requirements.

Interrogator: Why does that matter?

Business Analyst: Stakeholder time costs money.

Interrogator: Why does that matter?

Business Analyst: It means that creating the requirements for the project costs more than it should. If we use consistent terminology in our requirements, then we should be able to complete our requirements cycles faster. Oh, and it also means that we’re less likely to build the wrong thing and have to waste development resources reworking the system.

Interrogator: Nice!

Executive Level Summary: Business analysts help reduce the costs of project implementations by bringing clarity to the requirements. One way they do this is by using consistent terminology in their requirements.

Any activity we do can be diagnosed in this way. But sometimes the answers are not quite so flattering. Let’s interrogate the infamous “software requirements specification.”

Interrogator: How does “creating a software requirements specification” create value for our organization?

Business Analyst: This document tells us everything we need to know about building the system. Sometimes its 50 or 60 pages long. We’re really detailed.

Interrogator: Why is that important?

Business Analyst: Well, if we don’t document everything, we’ll miss something.

Interrogator: I can see that how it’s important not to miss something. How does the document ensure we don’t miss something?

Business Analyst: Well, we conduct a walk-through with everyone that needs to know what’s in the document and everyone that will be building what’s in the document. That way we know it’s complete.

Interrogator: Why does the walk-through ensure that nothing is missed?

Business Analyst: [Blank stare]

Now, your answers might be different. Maybe your software requirements specifications are required for regulatory reasons or you’ve found a solution to organize a walk-through of a long document that ensures completeness (I haven’t).

The point is not so much to pick apart a process that receives an almost constant beating. The point is to challenge you to evaluate your process with the same rigor your interrogator might do. What if this interrogator was your CFO or an external consultant who had promised you boss to find ways to reduce the costs of building software? Would you be able to justify the activity is worth your effort and the effort of your stakeholders? And, even if you could, are there other approaches to the same problem that would work just as well or better?

My challenge to you is to begin your week by looking at your calendar and to do list and asking yourself “why” for each significant item on the list. If you don’t know the answer, start researching it with your peers and your manager. Focusing on “why” is one of the most impactful career habits you can develop, both in becoming a promotable business analyst or in framing up your applications for your next job. We do it in our projects, why not also do it for our careers?.

1 “Why Business Analysts are so Important for IT and CIOs” CIO Magazine.

Don’t forget to leave your comments below

Laura Brandenburg is a business analyst mentor and author of the free “3 Career Habits for Successful Business Analysts“, a primer to becoming a promotable business analyst. She hosts Bridging the Gap, a blog helping business analysts become leaders and advance their careers. She has 10 years of experience leading technology projects and has helped build business analyst practices at four organizations. If you’d like to learn more about discovering and increasing your value, including an ROI framework for business analyst activities, additional career habits that help you increase your ROI, and techniques for communicating your value to stakeholders and managers, check out Laura’s upcoming BATimes webinar.

Working with Business Analysts Made Easy

Written by Mark Jenkins on September 7, 2010. Posted in Articles.

Over the last few years, many people have asked me for tips, techniques and skills you should develop when managing a group of business analysts. This article is an informal list BA managers might consider, especially if they are transitioning into management from a Business Analyst role.

Develop a BA Process

Provide a framework to which all your BAs work. Not only does this give them a consistent approach, but you a get a consistent way to assess their progress. Business stakeholders and IT staff should recognize a similar pattern in every project. In doing this, you are also training your stakeholders to think like a BA. After repeated exposure, they can foresee the next steps and come more prepared to meetings and projects.

Develop Consistent Tools and Standards

One of the worst things for a business user or developer to see is different documentation standards from each BA. I insist that everyone uses standard templates and adopts a consistent approach to diagrams and other supporting information. Be sure to make your templates flexible and try to refrain from producing overwhelming or heavy documents. I encourage BAs to try to separate documents as logically as possible. Having a functional requirements document full of use cases, mockups, data specifications and a report catalogue can quickly become a 100 page+ document and business and technical staff struggle to read it.

Get Involved in Planning Projects and then Leave the BA to it

One of the realizations when you move into management is that you cannot be everywhere all the time. More importantly, you understand that you don’t want to be everywhere all the time! It’s challenging when you move from being responsible for your own projects, running meetings and getting involved in as much detail as you like, to only having time to view projects from the periphery. One of the methods I use to stay involved, but not participate on a day to day basis, is to work with the BAs at the start of the project, to ensure they plan their efforts and evaluate the scope of their projects in a consistent and clear manner.

The scope evaluation typically takes the form of what I refer to as Power Verbs. These are the action points that you can then use to maintain your sense of the project. For example, if the project was to move house, the Power Verbs might be Investigate, Decide, Prepare, Pack, Move, Unpack, Recover. I would then spend time to expand each Power Verb into a series of action areas. These action areas then allow the BA and the manager to ensure that a project starts off with a clear understanding of potential scope. For the manager, this affords an opportunity for context any time they need to get involved, because they a basic understanding of the overall process.

By overseeing planning and providing a solid framework within which the BA can operate, the BA is free to use their own techniques and methods, while the manager is comfortable knowing the scope will be addressed.

Resource Your Team Well and Review it Constantly

One of the major areas of challenge for a manager is resource management, especially in fast paced environments. I use a tried and tested technique which I documented here, it has not failed me yet. However, regardless of which method you use, you need to find the right resources and resist the temptation to take on projects or problems yourself. It is not ideal if you assign a BA to a project and then they have to leave a few days later, because you forgot they were required on something else. I find that BA’s max out on 2 large projects or 3-4 smaller projects at any one time, any more and they lose the consistency needed to stay focused and add value. You will also want to track the time spent utilized vs. down time, as this will be a key measure in your demonstration of your success in resourcing your team.

Find a Way to Reduce BAs Moving from Project Area to Project Area

If a BA has to move business areas on each project, you will easily waste time unnecessarily as they need to ramp up to a new environment each time. To prevent this, assign your BA’s to a business area or project type and try to keep them there. As the BA gains experience they become more familiar with the stakeholders, processes and systems, they will reduce ramp up time to zero and add more value to the project. On a yearly or bi-yearly basis, try to switch the BAs around to keep them learning and developing.

Over Invest in Recruitment Efforts

Many managers are nervous about interviewing and recruitment and as a result hire the wrong candidates. If you are hiring BA’s, think about the qualities your candidates should demonstrate and try to use behavior based questions that call for specific examples. I will typically ask BA’s to do a live iteration exercise or some other activity relevant to the job to get a better sense of their real world performance. It’s better to take your time to hire the right skill set than to rush and hire the wrong person.

Don’t Forget the HR side

Being a good manager requires skills that you may not have developed as a Business Analyst. To make it harder, BA’s are usually smart people and need a specialized management style. They generally hate micro-management, are creative, and by nature are always finding problems that you’ll need to develop into opportunities. Encourage a collaborative style and get them involved with how the group progresses.

Meet as a Team Regularly

Schedule a weekly or bi-weekly meeting to talk about projects and status. You’ll find numerous instances where BA’s are overlapping or suffering from a similar pain point. Talking about these issues in a group format allows everyone to learn for very little effort.

Develop the Skills of your People to Improve Team Performance

Invest in team training but identify the skill deficiencies at the individual level. There’s really no point to sending your whole team on a use case course, if only one of them doesn’t know how to do them. Also, get creative and proactively look for free webinars and events. One of the easiest ways to develop a sense of where each BA is at is to create a competency model, specific to your process and to your environment. Use the competency model to guide where a BA needs help and improvement. It is also a great tool for managers to show leadership how the group is developing over time.

Establish Membership with the IIBA

Sounds expensive but it isn’t at all. $95 per BA for the year and you have access to a wealth of information and potential connections. The corporate membership is also a great deal and isn’t that much more expensive.

Don’t Forget your Stakeholders and Customers

As a manager, you represent your group to the wider organization. You will need to develop and maintain partnerships with your customers, especially the challenging ones. Enterprise Analysis is a great way to stay engaged as a BA Manager, but inevitably you are now going to focus on your relationships with stakeholders, ideally higher up in the organization. Don’t forget that the judgment of your success often lies in the perception your customers have of your group. It’s helpful to research how effective account, product or relationship managers operate, to give you some tips and techniques in this area.

Also, don’t forget to get to know your new peers. Build new relationships with the other managers you work with. Find out the pain points they have with your team and offer to help by changing things that aren’t working.

Change your Relationship with your Manager

You will now have a different working relationship with your manager, possibly even a different manager entirely. You have to recognize that there is more of a strategy element to the management role than was required for your role as a BA. Focusing purely on tactical and not strategy is going to quickly disrupt progress. One of the key documents to develop is a road map for your group, set some goals, establish a timeline, get all your team involved and then manage to a plan.

Remain Positive, be Enthusiastic, Lead by Example

As the leader of your group, your actions and demeanor have an instant impact on the moral of your team. Your staff will be looking to you for leadership and you need to respond accordingly. When you interact with BAs in project teams, live, breathe and demonstrate the development you want to see in them. Don’t forget to reward your staff for a job well done, even if all you can afford is a thank you, it’s a great place to start!

To conclude, while this article is not exhaustive list of everything you need to manage BAs (nor will that list ever be completed) but I hope it has given you some ideas. Remember, there is really no need to start from scratch as you mature your team and develop your management skills. The internet (Twitter, IIBA, Bridging the Gap etc) and people going through similar experiences are great sources of information. LinkedIn is also a great way to connect with colleagues, it’s also a really great way to recruit!

Don’t forget to leave your comments below

Mark Jenkins is the Associate Director of Business Analysis at KPMG. Mark leads a team of 20+ Business Analysts at KPMG in a Center of Excellence format. Prior to KPMG, Mark established a highly successful Business Analysis group at Internet Security leader Websense. Mark draws on his 8 years of Business Analysis experience, including numerous CRM initiatives and a wide range of projects, across all business areas. He can be reached at [email protected] and on twitter www.twitter.com/JenkoUK. Mark is also the Regional Director for the Americas Eastern Region at the IIBA and will be speaking, as part of a panel discussion, on Building a BA Career Center of Excellence at the IIBA Conference in October

The Business Analyst Facilitator Role in an Agile Software Development Team

Written by Mark A. Monteleone on June 22, 2010. Posted in Articles. 1 Comment on The Business Analyst Facilitator Role in an Agile Software Development Team

The purpose of this article is to define the need for the business analyst facilitator role in an agile software development team. Traditionally the business analyst role has been defined in the context of a project, utilizing the waterfall solution development life cycle (SDLC). This approach has the business analyst collecting all the requirements and business rules upfront prior to development. However, today’s demand for accelerated solutions has changed the dynamics of system development to a more agile approach, where requirements and business rules are defined in conjunction with solution development in iterative cycles. Hence, the question – “Is there a need for a business analyst role in an agile software development team?”

Some readers of this article may believe that the business analyst role is not needed with the agile approach. To those of this position, I encourage you to read on. I suggest regardless of the SDLC chosen (waterfall or agile), the role of the business analyst is still needed. As a developer, you may say, “but we are doing fine on my agile project without a BA role.” To you I ask, “Have you examined your expanded role of directly interfacing with stakeholders?” For the past 40 years in the IT business, I have experienced several approaches to solution development. One rule that does not seem to change is that regardless of the SDLC used, functions that roles provide remain. In the agile case, BA functions are absorbed by members of the software development team at some risk.

Please note, I am assuming that the reader is familiar with waterfall and agile SDLC approaches, so I will not attempt to define them in detail in this article. For the purposes of this article, a Scrum like process for the agile approach is used.

As an instructor of business analysis techniques and practices, I often field questions on the role of the business analyst (BA) in an agile software development team as opposed to the traditional waterfall solution development life cycle (SDLC) approach. After much thought and input from many sources, I am convinced that the role of the business analyst facilitator is needed in an Agile Software Development Team.

The Role of the BA Facilitator

The role of the BA facilitator is to guide activities on developing both the vision and software solution. The key word here is guide. The BA facilitator role provides process to group settings and avoids participating in content. Typically, the BA facilitator role serves as the liaison between stakeholders, and the stakeholders and software development team respectively. As the liaison, the BA facilitator role uses various techniques and emotional intelligence skills to assist project sponsors and/or team leaders in accomplishing group meeting goals:

Facilitation Techniques for Identifying Solution Features
- Creating a Solution Vision and Scope
  - Brainstorming – discussing of ideas
  - Brainwriting – submitting written ideas for discussion
- Eliciting Features and Associated Business Rules
  - Focus Group Meetings – soliciting opinions
  - Joint Application Design – resolving conflicts
- Analyzing Features – Assumptions, Constraints, Risks, and Issues
  - Root Cause – five whys, Ishikawa Diagrams
  - Force-Field – listing negative and positive influences
  - As-Is and To-Be Gap
- Making Decisions on Features and Priorities
  - Multi-voting – subjective paring down a long feature list
  - Criteria-Based Grid – weighting feature value criteria
  - Impact/Effort Grid – comparing feature benefits versus effort
Emotional Intelligence Skills for interfacing with stakeholders
- Active Listening and Paraphrasing
- Generating Participation
- Neutrality – focus on meeting process instead of solution content
- Questioning – seeking answers rather than posing solutions
- Maintaining Focus – use a parking lot and issue log for off agenda topics
- Obtaining stakeholder feedback
- Summarizing and synthesizing Ideas
- Conflict intervention

Under the agile SDLC, the BA facilitator role contributes in two main activities: Continuous Vision and Scope Sessions, Iterative Software Development Meetings and Workshops.

Every project starts with a vision and scope of the solution to meet a business need. This vision may be definitive or fuzzy. However defined, the vision will reflect a prioritized set of high-level solution features that is essentially the scope of work to be done by the software development team. In the agile approach, defining the vision and scope is a continuous set of sessions. Each session represents a snap-shot of the vision and scope at that time determined by the stakeholders. These sessions manage the scope of solution features either as additions, changes and/or refinements until the stakeholders complete their vision.

These vision and scope sessions are chaired by the project sponsor. The challenge for the project sponsor is to ensure that the project vision and scope is a collaborative effort among all the stakeholders, hence the need for the BA facilitator role. The role of the BA facilitator is to assist the project sponsor by providing and executing session plans. Each vision and scope plan consists of:

ensuring the correct participants attend
accounting for meeting risks
arranging for an adequate facility conducive to collaboration
setting an appropriate agenda

This agenda contains facilitation techniques that will lead the stakeholders to a consensus on a prioritized set of high-level solution features to be pursued by the software development team. During the session, the BA facilitator role uses emotional intelligence skills to ensure that all stakeholders participate and that their ideas are respected. The BA facilitator role ensures through “questioning” that the features are justified and can be traced back to the business need. Note that all features are subject to the approval of the project sponsor – chair of the session.

Iterative Software Development Meetings and Workshops

After the initial vision and scope features are determined, the Software Development Meetings begin with a consensus on which of the prioritized set of high-level features will be developed on the first iteration. Once a finite set of features is selected and time-boxed by the software development team, then a series of follow-on status meetings are held addressing progress and the removal of impediments. Between these status meetings, the software development team holds workshops with stakeholders to develop the solution. These iterative workshops conclude with a validation meeting of the developed solution and a decision on implementation by the project sponsor. In summary,

Select vision and scope features from prioritized list
Develop a solution for this iteration within a time-box
1. Conduct workshops producing prototypes
2. Hold status meetings on progress
Validate final prototype and implement with project sponsor approval
Return to step one for further features and add rework as needed until feature list is exhausted

Note that with implementation, the iterative software development meetings are renewed by another selection of prioritized high-level features to address. These features may have been changed by the stakeholders in the meantime by further vision and scope sessions held in parallel with the software development meetings.

The feature selection and status meetings are chaired by a team leader similar to a project manager. In these meetings, the team leader faces the same challenge as the project sponsor – ensuring that solution development is a collaborative effort through consensus. Once again there is a need for a BA facilitator role. As in the vision and scope sessions, the role of the BA facilitator is to assist the team leader by providing a plan for each meeting and executing that plan.

The software development team is self-directed and/or self-organized. The team runs the workshops according to their skills and experience, rather than using a set plan by the team leader. The workshops are direct conversations between the software development team and the stakeholders. These workshops involve vital business and technical details in developing the solution:

User and system functional requirements
Associated business rules
Information needed to be managed
User Interface
Technical implementation methods

Both what needs to be developed and how it is to be implemented are discussed at the same time during the workshop. As a result of these discussions, the development team provides a solution through a series of prototypes each tested with direct stakeholder feedback. The final prototype (for this iteration) is then validated and approved by the project sponsor for implementation. A new cycle then starts with the selection of further features from the vision and scope including possible rework items….etc, etc, etc.

In the workshops, the role of the BA facilitator is different from the previous planning meetings. During the planning meetings, the BA facilitator role provided and executed an agenda. The role of the BA facilitator in the workshop is to assist the stakeholders and the software development team to determine system requirements from stated user requirements for the purpose of building prototypes. The software development team uses these prototypes to build an incremental solution.

The BA facilitator role accomplishes the above by using an expanding BA tool which includes:

Business Modeling Tools for identifying and analyzing user requirements, system requirements, and business rules
- Activity Workflows with Swim Lanes – manual processes
- Use Case – user / system dialogue – system functional requirements
- Storyboard – user / system interface – screen flows
- Entity-Relationship – organizing information used by the system
- State Change – information changes as it proceeds through processes and systems
- Class / Object – use for Object-Oriented implementations

The thoroughness with which Business Modeling is used by the BA facilitator role is tempered by the needs of the software development team. Rather than comprehensive documented requirements as in the waterfall SDLC, the BA facilitator role generates “just enough” documentation as needed by the software development team to code the prototypes.

Conclusion – Formal BA Facilitator Role “Just Ensures”

Whenever solution features are being defined, prioritized, analyzed and/or developed, the BA facilitator role is used naturally to ensure stakeholder buy-in and acceptance of the final solution. Whether it is the vision and scope sessions, the iterative software development meetings or the workshops, the BA facilitator role may be taken on by a member of the software development team. However, consider the risk involved in building a consensus with someone less trained and experienced in BA facilitation. The level of productivity and consensus is directly dependent on effective use of the BA facilitator tool set. In addition, there is a risk that the stakeholder and the developer will focus on the technical aspects of the prototype rather than requirements. It is prudent to avoid this risk. To “just ensure” the success of the team, a formal BA facilitator assisting the agile software development team needs to be that best practice.

Don’t forget to leave your comments below

Mark A. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM^TM) and Certified Scrum Product Owner (CSPO^TM) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF). Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

This article first ran in the IIBA newsletter February 2009.

Stronger Together; Cultivating the Business Analyst and Project Manager Relationship

Written by Renee Saint-Louis on June 8, 2010. Posted in Articles. 2 Comments on Stronger Together; Cultivating the Business Analyst and Project Manager Relationship

Much has been written about the potential for a contentious relationship between the project manager and business analyst. If you have been a business analyst or project manager for any length of time, then you have probably experienced some of this tension for yourself, particularly if you have previously performed both roles. It can be difficult to find a happy medium when so many of the tasks seem to overlap between the BA and PM role. For example, PMs are used to managing relationships with customers and sometimes delve into requirements during status updates when the BA is not present. BAs can overstep their bounds by adding scope without the knowledge of the PM, thereby impacting project resources and timelines. It doesn’t have to be like this.

This article is the tale of two professionals – a BA and a PM – and how we learned to work together to form a strong partnership to deliver superior results for our customers. Our goal is to provide tips that worked for us that may work for you. This way you can recognize when you are in the storming phase and quickly take action to move you into the norming and performing stages so that you can excel in your work relationships.

Group Development Model

First, let’s start with the basic premise that all teams go through a similar pattern when learning to work together – as illustrated in the Group Development Model developed by Bruce Tuckman in 1965. The Group Development Model states that there are four phases of team development: Forming, Storming, Norming and Performing. As a team comes together they enter the forming stage where team members are introduced and get to know each other. This phase is usually brief and leads to the storming phase where team members jockey for position and test the boundaries of authority. In the storming phase conflict comes to a head and usually leads to a make it or break it point for a team. In fact, many teams don’t successfully navigate their way through this stage. For teams that can navigate these stormy waters, they find themselves entering the calm waters of the Norming stage. This stage is where team members dig in and focus on getting the job done. A leadership hierarchy is firmly established and teams can concentrate on the task at hand. Most teams stay in this stage for the remainder of the project. Some teams are fortunate enough to enter the Performing stage where true team synergy happens. Team members are inter-dependent and are able to handle the decision making process with little direct supervision. Of course, teams will move back and forth through the different stages of team development as circumstances change: new leadership, loss of a key team member, or project completion.

Our Story: Lessons Learned on the Front Lines

Forming a Relationship: Our relationship began when we were assigned to work together on a large, strategic IT project. Joan was assigned as the project manager and Renee was given the responsibility of the lead business analyst for the project. Throughout the year, the project team consisted of one PM, three to five business analysts, and numerous development and Quality Assurance resources.

Renee’s Perspective: The beginning of a project always brings uncertainty, ambiguity, and many questions. This project, with its strategic significance, was no exception. Joan and I were acquaintances but had never worked closely on a project together. In fact, the one brief time we had worked together, I was a complete emotional wreck that Joan had to talk off the ledge to get the job done. I was sure she considered me to be a complete flake! I didn’t know how much lee-way she would give me as a lead analyst and we didn’t formally define our roles and responsibilities. Our biggest mistake! This lack of definition, of who was responsible for what, led us right into the storming phase of the project.

Joan’s Perspective: Getting to know the team leads is a significant task. When forming a new team, I try to understand the leads. What makes them tick, will they follow through on tasks, are they growing into this role or are they experienced, will they truly be dependable leaders that I can rely on or will I need to help them along? Of course, the answers to these questions develop as you begin working together. In the beginning I may assume a more dominant role to be sure the team is heading in the right direction. This may mean setting up and facilitating sessions to determine and lay out scope. Now, if you are a trained PM, you know scope management is a key responsibility. However, BAs also assume this responsibility.

Stormy Seas Ahead

Renee’s Perspective: Being a business analyst lead on a team can mean different things to different people. To me, it meant taking responsibility for all of the analyst tasks on the project, ensuring analysts were meeting their milestones, working with analysts on the team to facilitate problem solving, addressing business needs, and, of course, writing requirements. During the beginning of the project, I noticed that Joan would often approach each analyst, discuss requirements approach, follow up on open items, and sometimes hold meetings where requirements were discussed without me. I felt like I was not being given the opportunity to lead the requirements effort. To address the issue, I pulled Joan aside after a meeting and brought forth my concern. I wanted her to be aware that I needed more of a leadership role and that I would like to work together as more of a partnership. While it is sometimes difficult to bring forth concerns that may cause conflict, I stuck with the approach of addressing the issues by bringing up specific situations and how I felt about them – not by accusing or blaming Joan. I knew her intentions were good – she wanted the project to be successful. I also knew there were two possible outcomes – Joan would either hear what I had to say and suggest a better approach to our relationship or she would become offended, defensive, and potentially make my life miserable. Fortunately, Joan is a level-headed person and listened to my concerns and suggested some actions we both could take to make things better.

Joan’s Perspective: Realizing that I needed to move the project ahead, I quickly set up scope planning sessions. On prior projects I had also coordinated the work assignments for the BAs on the team, discussed and helped set approach and, in some cases, I would be the primary contact back to the business sponsors on key requirements and scope changes.

I was genuinely concerned when Renee confronted me on my leadership role and how it overlapped with how she perceived her role. I knew we couldn’t be productive and have a solid team if we continued bumping into each other by trying to assume the same responsibilities. I was glad she felt comfortable enough with me to be open and honest and I welcomed her willingness to take on more responsibility by managing the tasks of the other analysts on the team.

Wanting to develop a solid, strong working relationship, we discussed in more detail what she wanted out of this project, as the lead BA and how we each picture our roles. I also expressed the concerns that scope management was a key factor to my role. So, we agreed that Renee would lead the scope meetings, but that I would be invited to all meetings. This way, I would be in touch with decisions, understand the project and be able to actively create a Statement of Work, maintain risk, issue and change logs and put together successful project plans.

I also suggested that we have weekly lead status meetings. This would give us an opportunity to connect one-on-one to openly discuss any issues we had with each other, project concerns, or just to get to know each other. Simple questions such as, ‘Renee is there anything you are expecting from me or roadblocks you are encountering that I can help remove?’, or more simply, ‘What do you have for me this week’ went a long way in building a strong relationship. We started understanding each other and how we can best work together and with others on the team.

The New Normal

Joan and Renee’s Perspective: As the year progressed we applied the solutions we agreed upon in storming.

We were very committed to our lead status meetings. Even though we did have to move them on occasion, we always had a weekly update. Through open communication we brought forth concerns without fear of repercussion or accusations. We began to understand each other and what makes each us tick, which led to trust and assurance in each other’s role.

The benefits of this led to a strong leadership team who weren’t in conflict with each other, and this helped the rest of the team focus their energy on getting the job done. In the end, the entire project team delivered what the customer needed when they needed it. Success!

Taking Care of Business – Performing at Our Best

Joan’s Perspective: A year has passed since Renee and I stormed through our first project together. We have grown together, learned from each other and trust one another. We are now on another large initiative together, where Renee is the lead BA and I am the PM. We continue to implement our key lessons learned:

Roles and Responsibilities defined: We held a team kick- off where the first thing we did was put together and agree upon roles and responsibilities. The matrix contained stakeholder, PM, lead BA, lead developer and other key roles.
Meet Regularly: Renee and I continue to have weekly status meetings. These have become instrumental in being in tune with the progress of the project from both of our perspectives. The one-on-one status has instilled trust, respect and friendship between the two of us.
Collaborate: We have learned to collaborate on key aspects of the project. We talk about approach and agree on it together, at the onset of a project. We facilitate and partner on the initial scoping meetings, discussing who will do what, when. We continue to bring forth concerns without blaming each other and creatively work out our differences.
Trust: Renee has completely taken over the leadership and work assignments for all BAs who are assisting her on the project. Through working closely together, I know we share the same goals and I trust her ability to see things through.

The greatest benefit is the fact that we truly enjoy working together and often request each other on projects.

Learning to work together is no easy task. The common denominator is communication and accepting the fact that you cannot take the storming process personally. You need to work together to resolve healthy conflict and work to a resolution that is acceptable for everyone. If you cannot do this, you will not be able to reap the benefits of the norming through performing process.

Don’t forget to leave your comments below

Renee Saint-Louis is a Sr. Systems Analyst with a subsidiary of The Schwan Food Company where she established and led an Analyst Center of Excellence. Prior to joining Schwan, Renee served as the Requirements Elicitation Practice Lead at a large insurance company. Renee has been a practicing analyst for more than 10 years. Contact:[email protected]

Joan Demuth, PMP, is a Senior Project Manager with a subsidiary of The Schwan Food Company where she leads numerous continuous improvement initiatives as well as serves as the lead project manager on several multi-million dollar IT projects. Prior to becoming a Project Manager, Joan served as a Business Analyst for more than 7 years. Joan has a Master’s Degree in Business Administration from the University of Sioux Falls. Contact: [email protected]