Skip to main content

Tag: Business Analysis

How to Demonstrate Your Value as a Business Analyst

Written by Kent McDonald on . Posted in Articles.

The fifth thing I wish I knew when first starting out was people do not want you on their team just because you are a business analyst.

Many organizations have rules in place that every project has to have certain roles assigned, and many people in the business analysis community suggest those kinds of rules should exist.

That can only get you so far.

Having those rules in place may help a Business Analyst get on a project, but unless you can demonstrate the value you add to a team, you stand a good chance of getting sidelined, and not invited back to the next project.

Here are some ways I have found to demonstrate my value to teams and organizations.

Build a Shared Understanding

In the article “Your Job is Not to Elicit and Document Requirements” I discussed a few lessons I have learned when working with teams. The times that I have had the best relationship with a team is when I follow those lessons. I do not view requirements as my ultimate deliverable, rather I see them as a means to the end of building a shared understanding. Everyone on the team knows what need we are trying to satisfy and the solution we are building to satisfy it.

What I am doing is managing risk – primarily the risk that the team forgets about key stakeholders or overlooks some important data or process relevant for the solution. If you keep your team informed about important data and process, communicate that information in an easy to consume way and help your team maintain their pace they will want to work with you again.

Point Back to the Need You’re Satisfying

You need to keep the team and your stakeholders focused on why you are doing the project. When you start a project, suggest the problem statement exercise I described in the article “Projects Tend to Be Described in Terms of Solutions” or some other technique to make sure you drive back to the real need you are trying to satisfy and how you’ll know when you’ve met that. Then take the output of that exercise and post it where everyone can see it. Then take the output of that exercise and post it where everyone can see it. Then, we you find yourself involved in the inevitable discussion (argument) about whether some feature should be included, or how to go about doing it, point to the problem statement and ask “will what we are talking about help us do that?” Decision Filters can provide the same type of guiding star.

When you are in the process of creating a backlog, do not just dive in and brainstorm a bunch of things to do, but start with your outcome – the need you are trying to satisfy, and then identify what specific things will position you best to reach that outcome. This is the general idea behind feature injection, and a helpful technique for structuring that conversation is Impact Mapping.

If you are in the midst of a project and you sense that the team does not all share the same understanding of the need you are trying to satisfy, or realize you are trying to satisfy a need, suggest that you stop for an hour and create a problem statement. The goal is not necessarily the problem statement itself, but the conversation that comes with it.

Remember that other members of the team are focused on other aspects of the project:

  • How will we build it? (developers)
  • What happens in this case? (testers)

While they all may have the reason for doing the project in the back of their heads (and the good ones can hold multiple concerns front of mind at the same time) they are also probably subconsciously counting on you to keep an eye on those things.

They may act annoyed when you bring these questions up, but trust me, in the immortal words of Col Jessup (A Few Good Men) “…because deep down in places you do not talk about at parties, you want me on that wall, you need me on that wall…”

Drive Decision Making

I was talking to a friend the other day about her day at work. She had a rather stern conversation with her client because the project she was working on was falling behind; not due to a capacity issue on the team, but rather an inability of the client to make and stick to decisions. To make matters worse, the client frequently hid behind process (oh, well if we have not made those decisions yet it must be because the due dates on the decision log are wrong) rather than taking steps to get decisions made.

She faced a situation that many BA’s face – you do not directly make decisions, but you are certainly impacted when those who are supposed to make decisions do not.

If you want to be in high demand, even if you are not the real decision maker, take it upon yourself to be the person to make sure those decisions get made. There’s a variety of ways to do this. For those of you who like to look at things in terms of a process, here are the key steps in the decision-making process:

  • Determine the decision maker. Before decisions need to be made, encourage your team to discuss who is going to make what type of decisions. It is often helpful to adopt a RACI matrix to remember what you discussed. Having this discussion before the decisions have to be made will increase the chances that decision making is distributed to the people who will have sufficient information to make that decision.
  • Select a decision mechanism Each decider is going to have their preferred decision approach. Know what those are, and also know which situations are better suited for one mechanism over another. Help the decider determine that mechanism.
  • Determine what information is needed. When a decision comes up, ask the decider what information she needs to make that decision, then pull that information together for her. You can have a lot of influence in the way you pull this information together, so be aware of cognitive biases.
  • Make a timely decision. Discuss when the decision needs to be made making sure you are not deciding too early without a good reason or procrastinating too long without a good reason.
  • Build support with peers/ stakeholders. Sometimes the choice of decision mechanism can help build support – the more collaborative the decision mechanism, the more likely you will build support in the process of making the decision.
  • Communicate the decision. Help the decider spread the word about what she decided.
  • Enact the decision. Help the decider determine the most effective way to enact the decision.

If you follow those proactive steps and still don’t see timely decisions happening, you can always revert to polite nagging backed up with a clear explanation of the consequences of a delayed decision. Sometimes people delay making decisions because they do not realize the consequences of not deciding in a timely fashion.

Be a Good Team Member

As I mentioned in my last post How To Learn New Techniques, you often get the opportunity to expand your toolkit by helping your team members out when they get overloaded or hit a bottleneck. Ask “how can I help” more often and try to eliminate the phrase “that’s not my job” from your vocabulary. Keep in mind that anyone can be the bottleneck at any given time. Sometimes you help someone else out, and sometimes you are the one who needs help. Part of being a good team member is admitting when you need help and helping your team members help you by coaching them in analysis skills when they pitch in.

Another aspect of being a good team member especially applicable to BA’s is do not make commitments for your team.

We have all run into this. You are in a meeting with stakeholders, the rest of your team is busy developing and testing, and you get asked: “When will this be done?” Unless your team has already plotted that out, resist the urge to make a commitment to your team.

Wait, you may be thinking, what if you say “well I think we can get that done this week” surely the stakeholders will realize that is just your guess and will treat it with the proper grain of salt. They will not. The minute you, as the team’s representative, indicate any time frame, it is viewed as a commitment, whether you intended it that way or not. It is perfectly fine to say “let me check with the team and get back to you.”

How Do You Show Your Value?

Those are some of the ways I have found useful for demonstrating my value. What have you found that works? Leave your experiences in the comments.

Strategy Spotlight: 6 Ways Analysis Produces Strategic Insights for Business Success

Written by Richard Lannon on . Posted in Articles. 1 Comment on Strategy Spotlight: 6 Ways Analysis Produces Strategic Insights for Business Success

This is one of the topics I have struggled with over the years.

Not because I don’t feel I understand it but because I meet professionals in the business analysis and project management fields who say, I don’t create the strategy or provide insight; it is given to me. What a load of bull. The reality is you create strategy and insight just by the nature of what you do. Here are 6 Ways Analysis Produces Strategic Insights for Business Success.

1. Stop It!

Strategic thinking is an individual’s capacity for thinking conceptually, with imagination, systematically and opportunistically as it relates to the attainment of future success. There are many times through the application of business analysis, and project management approaches that you use your spidey senses to engage your ability to think strategically naturally. To think someone else is more strategic than you is nonsense. To quote one of my favorite lines from an old Bob Newhart Show on YouTube – Stop it! https://www.youtube.com/watch?v=Ow0lr63y4Mw

2. Past, Present and Future Insight

Every organization I have ever worked with needs the same three things no matter at what level you are working. Those things exist at the senior, middle, and operational level of every organization and are written clearly in the various industry’s body of knowledge. They are the present state, the future state, and insight into how to bridge the gap between the present and future. That is about it. You are doing problem-solving at its foundation. Chances are you do think about the present and ask yourself what the future should look like. Then somewhere your mind says, OK, what needs to happen to get there. Wow, a strategic insight that can provide value to the organization. You just applied the IIBA Body of Knowledge Chapter on Strategic Business Analysis.

3. The Brain Finds a Way

I completely believe the human brain will always find a way when a problem is presented to be solved. It sometimes comes across as a flash like a camera taking a picture you can post on social media. There is a whole neurological science around the brain that has suggested we need to balance thinking with detachment to create insight. I’d have to agree. I think when you are emotionally connected to a subject matter it is far more difficult to provide objective insight. So that is why when you are too connected to a topic you should hand it off to someone else or at least talk to someone who is less emotionally connected. It might help. From business analysis consider the standard approach prepare, define, capture, analyze, integrate, refine and present your insights. Create a feedback loop. It helps.

4. Know What Insight Looks Like

I guess you can say good insight in business has some common traits. I think there is some truth to that statement. I know you can create a list of what insight might look like and then see whether your thinking holds the test at the time. Consider whether your insight has an impact, are practical and relevant, are based on facts, data and other evidence, deliver a picture beyond the surface, and there is little room for interpretation and people can easily understand them.

5. Personality Traits Matter

I was once asked by a CEO whether some personality types are more strategic than others. I said “Yes” and went on to explain I believe some people are more “What and Why” and others are more “How To” or tactical. That does not mean the latter does not have strategic insights. If everyone on your team were strategic all the time, nothing would get done. So it requires a balance of people with the right combinations of traits and personality to work together to have impact and team with success. There is another part of this puzzle. The ability to apply their expertise, have a purpose, be analytical, use intuition where needed, be willing to experiment, listen and drill deeper when needed. I do think it is also important to not think you should always have the answer. The answer should come through discovery.

6. Gain Insight into Purpose

Strategy insight is done to achieve a purpose. No clear purpose, poor insight. It is that simple. It becomes the “Fish on Land” syndrome. Sad but true. So this means you must have a focus or provide a focal point. I think this is where good leadership and definition of a problem comes in. Are you looking to implement a new system, expand your market, save on the bottom-line? There is a lot of literature providing approaches to help you gain strategic insight and develop a clear purpose for the organization, for a team and even for an entity of one, an individual. The greater the understanding of purpose, the better the strategic insight, solution, and implementation.

Final Thoughts

This is one of those topics that puts the hair on the back of my neck up a bit. I see so much potential business brainpower not being tapped in organizations. Even this morning I was reviewing career posts for an organization curious as to what people were saying. The pros were salary and benefits, and the con is that it was a death sentence of the brain. All I could think is that if you are looking for the strategic insight, it was not going to come from within this organization. If strategic insight were presented, nothing would move forward. People need to be strategically engaged in their thinking it is how we solve problems. Insight happens at all levels, not just at the top. As a professional know the ways you provide strategic insights.

Remember: Do your best, invest in the success of others, and make your journey count.

5 Trends in Business Analysis, Project Management, and Agile for 2017

Written by Elizabeth Larson on . Posted in Articles.

Since 2009 we have enjoyed reflecting on what’s happened the previous year on projects and making predictions for the upcoming year. To summarize the `trends” we saw in 2016:

  • Emergence of the Business Relationship Manager (BRM) to maximize value
  • Agile successes, challenges, and use beyond software
  • Trends in business analysis and project management certifications
  • Implications of a changing workforce

Here are five industry trends we see happening for 2017. We’ve added two brief bonus trends at the end of the article.

1. Business analysis as a focal point for scaling Agile

Many organizations are delighted with the results produced on Agile projects, but are struggling with its application on large, complex projects, as well as its adoption enterprise-wide. Many of the discussions focus on which Agile framework works best for scaling Agile. Some of the common frameworks often discussed are scrum of scrums, Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Nexus.

  • Large, complex projects. While there is a great deal of contention about which framework is “best,” there seems to be an agreement that there is a need for coordination, integration, and communication among Agile teams related to the solution being developed. Regardless of the title of the person doing this work, it is business analysis work. And it’s work that has always been needed on large, integrated projects—the coordination of dependencies, security, business and technical impacts, and version control.
  • Enterprise-wide Agile. Many large organizations have adopted Agile in a hodgepodge of ways, and these different areas have become quite fond of doing Agile “their” way. Adopting Agile across the enterprise will require skills of people not only familiar with Agile, but also with understanding the Agile current state and working with stakeholders to reach consensus on a unified future Agile state. This will involve being able to influence, resolve conflict, and to think both creatively and critically—skills well suited to experienced BAs.

2. Digital Transformation: Profound Change for Business Analysis…or is it?

The “digital transformation” movement means we must change the way we handle business analysis and requirements. Or does it? Consider two trends commonly mentioned today.

  • Cloud Computing. Security is a bigger concern when storing data in the cloud than if it is on-site under “lock and key.” Considerations for recovering data must be employed over and above normal backup and restore. Access rights are also more complicated than with traditional applications.
  • Mobile apps. Mobile applications provide data for sensitive banking, investment, or insurance applications. Security is a bigger concern on mobile devices given they are, well, mobile. It is much easier for a thief to access a bank account from a mobile device than a desktop. Modern apps need to have “mobile responsive” features and usability.

What we conclude is that these two technical trends will continue to affect business analysis. The trend, though, is not so much with functional requirements as it is with non-functional requirements (NFRs). The two examples above feature important NFRs including security, accessibility, recoverability, and usability, including user experience. NFRs are traditional aspects of business analysis, and any profound effect on it is that we will need to pay even greater attention to them with digital transformation.

3. Freelance BAs and PMs in the Gig Economy

Currently 40% of the US workforce is part of the Gig or on-demand economy1 and that number is growing. Intuit breaks this on-demand economy into 5 groups.2 We describe these groups below and briefly discuss how they apply to the project manager (PM) and business analyst (BA). Here are the 5 groups:

  • Side Giggers (26%). These are PMs and BAs who want to supplement their existing income. Examples include PMs and BAs who take vacation, days without pay, or who work off-hours to do training classes or short-term consulting gigs.
  • Business builders (22%). BAs and PMs who are tired of working for others and want to be their own bosses fall into this category. Many of these will create their own companies and hire others. We can expect these companies to be based on the owners’ experience in project management and business analysis. Examples include consulting and training companies.
  • Career freelancers (20%). These PMs and BAs love their work, love working independently, and want to use their skills to build their careers, not to build a company that hires others. These folks usually establish themselves as independent contractors with their small own company, usually an LLC.
  • Substituters (18%). PMs and BAs who want to work in the gig economy temporarily. Whether laid off from their former organizations or for other reasons they view “gig” work as temporary while they look for full-time employment.
  • Passionistas (14%). PMs and BAs who love what they do and are primarily motivated by their desire for greater flexibility than is usually provided by a more traditional organization.

4. The shifting sands of the BA and PM roles

Many project professionals find their roles changing so rapidly that it feels like the earth is shifting below their feet. Roles are being combined (BA and PM or BA and QA) or being torn apart (formerly hybrid PM/BAs are now full-time PMs or BAs). In some organizations BAs thrive on Agile projects working hand-in-hand with product owners (POs), while in others become part of the development team doing testing because there are no BAs,. PMs become scrum masters as do BAs. Sometimes the BA becomes a product owner, but one without the authority to make decisions.

In addition, both BAs and PMs are working strategically, doing business cases and recommending enterprise-wide solutions. And more and more organizations recognize the importance of the business relationship manager (BRM), to maximize value and help set the strategic agenda.

So what is the trend? For the foreseeable future, roles and titles will vary widely from organization to organization. Equally certain is that both project management and business analysis work, both strategic and tactical, have always been required and will always be needed, regardless of the role or the title or the role.

5. Generalists helping teams to self-organize

If descriptions of job openings are an indication, specialization seems to have wide appeal. But breadth of capabilities will continue to provide the flexibility that organizations need to respond to the hyper pace of change. BAs who code. Engineers who do project management. It’s the number of arrows in the team members’ quivers that defines an organization’s competitiveness – and contributes to the team’s ability to self-organize. Not only do organizations need self-organizing teams, but the teams themselves also need the flexibility to pick up tasks that are ready to go, so the more diverse the team members’ skills, the more work can be done in parallel and completed sooner.

Although varied work appeals to many younger workers, this isn’t just about attracting millennial talent. Self-organizing teams provide the structure organizations need in order to react quickly. Self-organizing teams and the ability of team members to wear multiple hats and get things done as they see fit will continue to become the best way for organizations to respond to external influences. The self-organizing team is not a new thing, but it is going to increasingly become the norm.

Two bonus trends

  • Short business cases and quick value. The trend is to provide business cases on slices of the initiative, slices that can bring quick value to the organization, rather than spending weeks or months detailing out costs and benefits and a return on investment showing a multi-year payback.
  • Dev Ops3 This trend relates to the first and fourth trends, scaling Agile and the shifting project roles. BAs and PMs now find themselves participating as DevOps Engineers on Agile teams that emphasize collaboration not just between the customer and development team, but also among such areas as development, operations, security, infrastructure, integration, etc.

Footnotes:
1 Forbes, January, 2016
2 Intuit Investor Relations, February 3, 2016, http://investors.intuit.com/press-releases/press-release-details/2016/The-Five-Faces-of-the-On-Demand-Economy/default.aspx
3 Dev Ops is “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.” https://theagileadmin.com/what-is-devops/. Ernest Mueller, Aug 2, 2010 – Last Revised Dec 7, 2016. He attributes this definition to Jez Humble.

About the Authors

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

Andrea Brockmeier, PMP, CSM, PMI-ACP, is the Director of Project Management at Watermark Learning. She has 20+ years of experience in project management and related practice and training. She writes and teaches courses in project management, business analysis, and influencing skills. She has long been involved with the PMI® chapter in Minnesota where she is a member of the certification team. She has a master’s degree in cultural anthropology and is particularly interested in the cultural aspects of team development, as well as the impact of social media and new technologies on organizations and projects.

Top 5 Considerations When Choosing a Business Analyst for the Complex Tech Project

Written by Brad Egeland on . Posted in Articles. 1 Comment on Top 5 Considerations When Choosing a Business Analyst for the Complex Tech Project

Anyone who has ever worked on a technical project understands the critical nature of the business analyst’s role in the success of the project.

Sure, the project manager is the project leader. But the technical leader? The technical liaison? No, not really…not if the project is large, complex and you are hoping for any degree of real success.

On the truly technically driven projects with a team full of competent tech developers and analysts, the project manager needs some technical know-how to pull off the leadership role with this group. But even more than that, he needs a good business analyst with the right skills and experience to make it truly successful. Specifically, there are four key considerations when selecting the right business analyst for the next big tech project. These four are…

Knows the material and technology.

Learning curves can be the downfall of a project. So can rework. And poorly defined requirements. All these things can happen if you have business analyst who is not up to the challenge of the technical material at hand and the chosen technical solution for the project. That’s why it is imperative on a technical engagement that is long, complex, visible or all of the above, to a have a business analyst assigned who is technically up to the challenge and not just “ready to learn” or “fake it till he makes it.” That could be disastrous to the schedule, budget, project manager and team…and to the customer.

Knows the tech staff.

A business analyst that has already worked with some or all of the technical staff assigned to the project would be a good idea. Why? Because there is always a “comfortability curve” that happens when the BA starts to interact with the tech leaders on the project and liaison between the project manager and technical lead. Remember, the BA is often the right hand man to the project manager and the most trusted confidante of the technical lead. That’s a tough dual role to fill and sometimes it can be a very fine line for the BA to walk throughout the project. A comfort zone with both the tech lead and the rest of the team is helpful to get everything running on all cylinders from the start and a history – a good, positive history – with the project manager is also very helpful.

Confident enough to make key tech decisions when no one is around.

There will come a time on a complex technical project when it comes down to a crunch time and the business analyst must make a “stop-go” decision or a “this way or that way” tech decision. Sure, they may get tech lead input, but may not have the project manager available to take the heat or the CIO around to lend input to the decision-making process. It’s during those times when the business analyst that you really need in this role can rise to the occasion and say “this is the way to go” and do it with confidence…. or at least fake confidence if that’s what it takes. No one really wants to take the bullet… but being willing to is half the battle. That’s what you need from the good BA on a complex technical project.

Has connections in the organization.

As important as it is to have a project manager who is well connected so that he or she can get roadblocks knocked down, financial information for the project promptly as needed and input for key decisions fast from leadership. Not surprisingly, it is just as important for the business analyst to be well connected. In the technical BA role, the business analyst needs to be well connected to people like the CIO or CTO, development managers and other technical team leads and analysts who have “been there, done that” so that information can be shared quickly and decisions won’t get delayed. A good tech BA already has 90% of the knowledge needed, it’s that coverage and assistance on the other 10% that can sometimes keep a complex project from running off the rails.

Works well with the project leadership.

Finally, finding a business analyst who works well with the project manager on any given project – not just the complex, technical ones – can be extremely beneficial to the success odds of the project. Communication comes easier, leadership roles are tried and true and already understood. The honeymoon phase is over and the real work can start from Day One. And that’s a very good thing for the project, timeline and customer. Those awkward moments when they step on each other’s feet are avoided or already out of the way on another project in the past and the team can gel under this sort of co-leadership functionality. Because let’s face it, when decisions are happening and meeting and communication with the project team and client are in progress, the project manager is the leader. When the technical requirements are being defined and the business processes are being understood and interpreted, the business analyst is more of the leader at that point and the project manager is often very happy to be relegated to “note-taker’ status.

Summary / call for input

When you read this list you can see that “experience” and the right experience is the common theme. The experienced business analyst will know the technology, will have worked with the tech staff before, will be comfortable making critical decisions on his own, will be well connected in the organization and will have worked with the project manager before on another project, most likely. I should probably add “get along with everyone” but that’s sort of implied here. The BA doesn’t need to be everyone’s friend, but may need to act like it at times to get things done on the complex tech project.

Readers – and business analysts – how do you feel about this list? Do you agree? What would you change about it or add to it? Share personal experiences that help generate discussion if possible…we can all learn from great discussions!

Project Managers: 7 Things They Want Their Business Analysts to Excel At

Written by Brad Egeland on . Posted in Articles. 1 Comment on Project Managers: 7 Things They Want Their Business Analysts to Excel At

I decided to perform a bit of a survey or experiment or whatever you want to call it.

I decided to ask several career project managers I’ve personally worked with and a few that I’ve connected with online as to their thoughts on what they wished, wanted or were grateful that their business analysts excelled at on the projects they managed with them. After rummaging through their wishful and rambling responses, I’ve come up with these 7 general themes…

Customer interaction.

The project manager is the key customer facing individual on the project. No question. The PM leads the initial project activities with the customer including kickoff, weekly status calls, and ongoing – potentially daily and sometimes hourly – communication with that project client. But having a business analyst who knows their way around the customer is a huge benefit to the project manager, the team and the project in general. When I’ve had business analysts who felt comfortable conducting meetings and requirements definition sessions with the client on their own, it’s freed up my time and mind to handle other activities on the project, charge less to the given project thus keeping the budget in good health for when issues need to be addressed (and there will be issues!), and perform other work on other projects.

Being technical.

This could also read “being familiar with whatever processes necessary given the industry the project pertains to.” I said “technical” because I’ve really only ever led technical projects. Having the right industry and technology knowledge will smooth the communication process with the project team that the BA really needs to have in order to be properly effective.

Tech documentation.

When the project manager has a business analyst who knows their way around a good project document deliverable, it is truly a great thing. I realize experienced PM’s and good BA’s probably take this skill for granted, but it is not a given. Nor is attention to detail which can lead to error-prone deliverable documents. I know, I’ve had it happen. It resulted in me and my team going to peer reviews on every deliverable going forward due to one business analyst producing three consecutive error-prone versions of the same documentation deliverable.

Being organized.

The organized business analyst contributes greatly to the project engagement without needing close supervision and oversight that a less experienced and less organized business analyst otherwise would. When the PM has confidence in the BA’s ability to just take the ball and run with it on decision-making, project team communication, and customer interaction, the freeing affect for both is incredibly productive.

Handling project budget issues.

I think most business analysts are pretty smart when it comes to expenses on the project. They think more like PM’s who are accountable for such things than tech team members who expend the hours that are in the budget and need to show 100% (or close to it) utilization. In other words, most business analysts – unless they are tech leads dually acting in the business analyst role – know they are considered more “management” than not. I’ve always said that keeping the project budget within 10% of target makes it much easier to stay on track in terms of dollars and budget. Staying in the 0-10% range means you’re always in the zone of “acceptability” and it isn’t likely to go crazy and leave you with a 50% budget overrun to try to fix…which you won’t likely ever be able to do. Having the business analyst who can understand that and help manage that budget and keep it on track is win-win.

Leading meetings.

This one is more than just customer interaction, of course. The business analyst, in many cases, is like the team lead. Interacting very, very closely with the tech lead on the technical projects in the requirements definition process and translation of those requirements into functional design documentation and a technical design document from which a viable project solution can be built. The BA must be, then, a trusted and accurate and effective project communicator. One who knows how to plan for, facilitate and followup on meetings with the team – and the customer, of course. Knowing how to run a status meeting, take notes, put together a meaningful agenda and project status meeting goal and how to follow up afterward with participants to ensure everyone has landed on the same page. Also, as important, is knowing how to put the right people in the seats at every meeting they conduct. It doesn’t do any good to call the right meeting to discuss the right topic if no one shows up. if you can run a good meeting that makes people want to attend and participate in rather than avoid, then you are golden. Someone who can get 100% attendance and participation is critical to project success.

Understanding PM processes, practices and tools.

Finally, yes…they may not be dually acting in the role of the project manager, but knowing how good project management executes and delivers is very helpful. That way they understand what the project manager is doing, is responsible for and probably will need help with. The more the PM and BA know about each other’s roles, the easier and more productive that relationship will be. And that’s a good thing. Think Batman and Robin. And the PM is not always Batman – it depends on what the responsibility is at the moment. They work well together and help each other out. Not quite like completing each other’s sentences…that would be weird. But close. BAM! POW!

Summary / call for input

The project manager and business analyst should work hand in hand together in a perfect world. Nothing is perfect, but my most successful projects have certainly been spent working with a business analyst who could take the ball and run with it. And most I’ve ever worked with have been able to do that – it seems to be in their nature and work ethic and it certainly makes the project run more smoothly and has always resulted in a more confident and satisfactory delivery team to project sponsor relationship.

Readers – what’s your take on this list? If you weren’t included in my small survey…and yes it was a very small pool…then now is your chance to share your thoughts and experiences. Do you agree with this list? What would you change about it? Please share and discuss.