Author: Brad Egeland

Why Are Business Analysts so Critical to the Project?

Written by Brad Egeland on November 1, 2018. Posted in Articles.

Ok, the question from some of you may be… “says who?”

Basically, you may be thinking, “Who says they are so critical to the project?” I do! And I’m pretty sure a lot of individuals who are deeply concerned with the success of the project they are leading or working on would say the same thing.

A good business analyst can make or break the project, in my opinion. I’ve one business analyst that the project customer liked so much that they paid an extra $100,000 in change orders just to have him work onsite at their location for the second half of the project even though the project was already running smoothly. Now that’s customer security and satisfaction.

So back to the question, why are business analysts so critical to the project? And I’m going to approach this from the tech project angle because that is my entire background and experience. In my opinion, here’s why good business analysts are so critical to the project…

They…

Run the casual side of the project.

The project manager is going to be leading the weekly formal project status meetings and any quarterly or ongoing project review sessions. That’s usually a given. However, the more informal leadership of the project team – oversight and daily management of the tech project team – and daily interaction with the customer side project team is going to happen mostly at the business analyst level.

Manage the tech team.

While a good project manager with a tech background can do a pretty good job as far as credibility and leadership in leading the tech project development team, the credible, experienced, and leadership-oriented business analyst can do it better. Team discussions, directions, conflicts, resource issues and resource forecasting input are all going to be daily activities for the business analyst role. The tech team will need guidance, direction and requirements interpretations on an ongoing basis – often daily on many projects. This guidance and direction and any decision making would be too far delayed if it always had to go through the project manager. The business analyst will handle this and keep the project moving forward through thoughtful, experienced, and proactive action and decision making.

Lead the requirements definition effort.

Good, detailed, complex requirements are the lifeblood of the project. While the project manager leads the project overall, it’s the business analyst who will be reviewing detailed business processes, meeting with the project customer to fully understand those process, work with the project team and customer to turn business processes and high level requirements info detailed and documented project requirements, create functional design specifications and lead the project team into the technical design phase of the project. It’s nice to think that the project manager is going to do that, but on most tech projects the business analyst will do most of that real work on the technical engagement.

Make key creative decisions daily on the project.

Yes, major decisions are going to involve the project manager as often as possible. The project manager is the one with the project success or failure target on their forehead. And communication is their top priority. But the business analyst in the trenches with the team and customer will be making on the spot and on the go decisions almost every day on the design and development side of the project that may never involve the project manager. Can you imagine how much it would slow a project down just to clarify a report field or design element on the tech project through the project manager? It’s not logical, or necessary – especially if you have the right leader and experience in the business analyst role on the project.

Keep the project customer engaged and focused.

A disconnected project customer can actually be very damaging to the forward progress and success of the project. When the project customer disappears for long periods of times, it becomes difficult to get certain tasks accomplished. Status meetings become difficult if not impractical, requirements interpretations are difficult and if the customer isn’t involved it may be impossible, and those ongoing daily decisions that must be made can be very frustrating and lead to improper forward progress if the customer involvement is zero. The experienced and leadership-oriented business analyst will keep the project customer engaged as much as possible throughout the project by recognizing this challenge and working to keep the daily communications open with the client on an ongoing basis. The business analyst may need to “make up” tasks to keep the customer engaged, but they will work with the project manager to do everything possible to not let the project customer disappear to other projects or their regular organizational roles when their availability is critical to the project’s success and ongoing forward progress.

Summary / call for input

I’ve always said that the business analyst role can make or break the project. A great business analyst is – in my opinion – critical to the success of the project. The project manager has high level oversight of the project, but the business analyst is working with the team and customer daily to achieve overall project success and their efforts can’t be incorporated successfully into any other role without the project suffering significantly. Too much communication, leadership, decision making, and customer engagement is needed from the business analyst role – especially on the big projects – to ignore the significance of this vital project team position. And on the tech projects, the more technical the business analyst is in terms of background and experience, the better.

Readers – what is your take on this? If you are the experienced tech business analyst, do you feel that I’ve covered this? What would you add or change about what I’ve projected here? What about project managers reading this – do you feel this is accurate or a good portrayal of your experiences with business analysts on technical projects? How critical does everyone feel this role is? Please share and discuss.

Making the successful transition from business analyst to project manager

Written by Brad Egeland on September 6, 2018. Posted in Articles. 1 Comment on Making the successful transition from business analyst to project manager

Not all project managers want to manage projects forever. Sometimes they look to switch to a more technical hands on position with the team like the business analyst role.

Likewise, not all business analysts want to continue in the role of business analyst forever – looking to take on a higher level management commitment of the project and deal less with the daily team and customer oversight that the BA role is usually responsible for on most project engagements.

If you are considering a move to project management from business analysis, below are some of the key areas where – in my opinion – you’ll need to take some extra steps or will need to focus efforts on in order to make the transition as successful as possible as quickly as possible. I’ve limited it to five areas – please consider and share your own thoughts that come up as you read this.

Training and certification.

If the business analyst is truly certain about making the transition to full on project management then a good start would be to go through the proper training and certification. Getting your project management professional (PMP) certification is the likeliest best route to take. The applicant must document the proper amount of experience to sit for the exam but there many places that can assist you that and even get you trained and certified within 5 days – with a 100% guarantee that you’ll pass it and if you don’t you get to take it again door free.

Learning the software.

Yes, there will be software involved. It’s 2018 and you’re not likely to manage a project over 100 hours without using more than an Excel spreadsheet. Whatever software tool you prefer or your new project manager colleagues recommend or your organization (or customer) requires you to use, learn it and use it. They are all fairly similar and you mainly want to be able to input your tasks and their scheduled dates, connected the dependent tasks, add resources to the tasks and associate costs to those resources. Once you’ve done that, you should be ready to go.

Thinking at 10,000 feet.

As a business analyst, you’ve probably been used to viewing tasks and requirements and business processes and design issues at very minute detailed levels. As a project manager, you do care about the details, but you have to get used to looking at most things – most of the time – at the 10,000 foot level.

Meaning at a very high level and analyzing the overall affect of tasks, task progress, issues, resource input, and task dependency, etc. at very high levels and how they affect the project now, a week from now, a month from now, how they affect each team member and the customer, and sometimes even how they affect other projects.

Making decisions.

The business analyst is always making decisions – probably just as many or more than the project manager that are important to the project. The decisions being made are often different – with the business analyst making decisions focused on – for tech projects – next design and development steps, requirements definition and interpretation issues and similar. The project manager is often more focused on making higher level project related decisions like task assignments, resource changes and needs, delivery dates, vendors to be used, etc. So the nature of decisions that the business analyst making such a transition will change and they must be comfortable making those decisions – sometimes quickly with less than enough information and possibly with no team members or stakeholders or even the customer available to provide input that may be needed for more project critical decisions.

Communications and meeting facilitation.

The business analyst making the transition to project manager must be a master communicator as it is jib zone for the project manager position. Communicator and meeting facilitator go hand in hand. It’s not enough to just disseminate information. You also need to be. A great listener, understand what’s being communicated and understand what lies behind and beyond the communication. Sort of interpreting someone the communication as it comes through because there can be some meaning to it that lied below the service. As far as meetings, it’s much more than calling an meeting to discuss a topic. Ores planning for the meeting, getting meeting info out to meeting attendees in advance Sao that they have time to prepare for what may be expected of them during the meeting to aid in information dissemination, project update, and decision making. And them taking great notes during the meeting f

Summary / call for input

Project manager. Business analyst. Both are leaders. Both must be excellent communicators, meeting facilitators, team leaders, decision makers and customer managers. But in slightly different ways. Each role prepares you well if you are interested in transitioning to the other. Perhaps the business analyst to project manager role is easier because you’ll already have that more hands-on technical feel that isn’t absolutely necessary for the project management role but can make life easier. The project manager making a move to business analyst may need to acquire that skill set and it may not be easy depending on the background the project manager is coming from. It’s my stance that every project manager leading tech related projects should have a technical background. Being a former application developer and application development manager has helped me in my project management and consulting roles in many ways and legitimizes my skills and understanding of the technology to tech project team that may not be the easies to manage from the outset and rarely trusts the non-tech project managers out there who try to give them direction.

Readers – what’s your thoughts on this? Have you made the transition one way or another? Was it easy? Hard? What about your experience in one or the other helped most with the transition? And was the move permanent or did you take it slow or go back? Please share and discuss.

Calling All Business Analysts: You are the Wave

Written by Brad Egeland on August 22, 2018. Posted in Articles. 2 Comments on Calling All Business Analysts: You are the Wave

Sort of like the straw that stirs the drink. Stealing a line from one of my favorite songs from one of my favorite bands… “In the middle of the world on a fish hook, you’re the wave.”.

Interesting twist, I always think. Gavin Rossdale, the main song writer and the frontman of the band Bush, is the writer and singer of these lyrics from the song “Swallowed” and he only talks about the world and the fish hook, yet he doesn’t call the subject of the song any of either of these. He refers to her as the wave that makes the world and fish hook bob erratically. Interesting way of thinking outside the box for these lyrics and the perfect way of expressing this concept.

A basic, boring definition of a business analyst is this… “A business analyst (BA) is someone who analyzes an organization or business domain (real or hypothetical) and documents its business or processes or systems, assessing the business model or its integration with technology.” But does that really sum up what you’re doing if you are a business analyst? Is this what you tell your friends or is it go a lot deeper than that. I’ve been a project manager for many years and my business analysts certainly juggle more than can be described or extracted from that generic definition.

Let’s wrap this up so my point becomes clearer. The business analyst is not the people in the middle – that’s the project manager, the project customer, the team. The great business analyst is really doing much more and in a way is “directing” the project – or being “the wave” that causes some of the most important tasks and processes on the project to connect and actually happen. They cause them to move forward. They do this mainly through these focused activities or project responsibilities…

Daily team touch base.

The business analyst is going to be the main touchpoint or contact for the individual project team members. It won’t be like that on every project and that can vary from organization to organization, but certainly a solid business analyst is expected to be the main contact on a team level throughout the engagement. It doesn’t have to be formal meetings, but checking in with the entire team is common and even providing the team with a daily status update for the project. The project manager should also be doing this – likely at a higher level and this business analyst daily call out could just be an add-on or resend with more detail or updates to that daily PM communication.

Liaison between project manager and team.

Certainly this is probably the most common overall activity that people think of when they consider especially the communication duties of the business analyst. On a tech project that business analyst will be the one throughout who is seeking out any further necessary discussions of or detailed definitions or clarifications of specific project requirements, getting and giving project status updates to the project manager and team and ensuring that smaller details aren’t falling through the cracks.

Frequent customer interfacing.

Likely no one on the project will interface with the customer as much or as often as the business analyst – even more than the project manager. While the project manager will focus more on organizational and status activities with the project customer, the business analyst focuses more on project dynamics and what’s going on at this instance sort of material and communication on the project. Requirements questions and clarifications, business process details, and anything that the tech team comes up with that needs to be asked of or passed along to the project customer.

Help the project team interface with the project customer.

To go a step further in clarifying part of the responsibility in that last item, the business analyst is going to be the primary point of contact between the customer and the individual project team members. Too much team communication between the customer and each individual project team member can lead to miscommunications, ever changing requirements, gold platting by a tech team member in over developing the project solution and an overall lack of focus for the team doing the daily project work. There needs to be a central point of contact – especially on tech projects – and the business analyst is that central contact point.

Daily touch base with the project manager.

Likewise, the business analyst will be in frequent communication with the project manager as each will likely serve as the other’s go to project person. Overall project communication responsibility will always be Job One for the project manager, but it isn’t far off the mark for the business analyst as well – both must be excellent and efficient project communicators, master project meeting facilitators, and great customer interfacers. Planning project next steps, key project communications and making joint decisions will always be part of the collaborative interactions that happen between the project manager and the business analyst on the engagement.

Summary / call for input

The bottom line is this – while the project manager is the person with the big red target on their head and holder of overall project responsibility and communication duties, the business analyst is at least their equal in all that – albeit often at a more daily, casual and even more frequent level. It is a more common situation to see a business analyst onsite with the customer 80-100% of the time than it is the project manager, who’s duties can mostly be performed from a distance. Often the business analyst is going to be in more daily contact with the customer and team and probably making even more key decisions over the life of the project than even the project manager is making. They are the “straw that stirs the drink,” or in this case they are “the wave.”

Readers – how do you feel about this concept? Do you agree? If you are a business analyst, do you feel like “the wave” in the middle of a world on a fish hook? Please share your thoughts and discuss.

The Best Business Analysts Ask Lots of Questions

Written by Brad Egeland on August 15, 2018. Posted in Articles.

If we want to be experts and be respected like experts and be paid like experts, then we aren’t supposed to be asking questions, right?

We’re supposed to be answering questions. The weak ask the questions and the strong answer them. The weak need information and the strong are the ones with the information. The weak are the followers and the strong are the leaders. Right? Wrong!

To get better is to acknowledge areas we need help in. It’s hard to get to that point – just like that innate tendency that men have to avoid asking for directions. This isn’t really true, but it’s one of those stereotypes we’ve all heard of. Or that all teenage girls are ditzy. Ok, this one is true… I have parented more than one and my 21 year old is still operating in that mode more than her fair share of the time – made obvious twice in the last two days.

But back to business analysts and the need to ask questions and get information. The best business analysts I’ve worked with have usually asked a never ending string of questions in order to discover full and true needs for the project, the overall business processes affected, and the detailed requirements for the project. In my experience, the most business analyst’s questions revolve around these four major activities…

Making the big decisions.

Certainly, any big decisions on the project are going to require information. And how do you get that information? You acquire it – often by asking for it. You can hope that someone has it all packaged up nice and neat for you but that will never be the case. No, the excellent business analyst will need to seek out this information knowing nothing is easy to come by and nothing is going to be served up on a silver platter. Besides, the project customer is no expert. You’re going to have to drag this information out of him. Even if you have access to the right some great subject matter experts (SMEs), you’ll still have to grill many or all of them because no one customer representative will have all the information you need.

Understanding the business processes involved.

You may consider some of these customer side representatives subject matter expert s on their business processes. But the reality of it is that most are not. Most do not have the 100% overall understanding of how their business works, how all the business processes play out that will be affected by the project and how those business processes translate into the complex, detailed requirements that are needed. It’s those requirements that the business analyst must help the project manager, tech lead and tech team get to quickly so the team can move forward with the design and development without burning through all of the budget set aside for planning and design. So the business analyst is going to go to far more than just one point person on the project to get processes defined and begin the arduous process of documenting the proper, real project requirements in the detail needed.

Defining requirements.

Next, the business analyst is nearly always going to play the top dog role in truly defining the requirements of the project. The project manager has overall responsibility for scope management and all stakeholders must play a role so that the project never goes off the rails from some oversight. But in terms of leading the requirements definition effort, understanding how the tech requirements tie into the business processes, and translating that into real project requirements, that’s going to fall to the business analyst 99% of the time.

Defining the technology or tech solution.

A business analyst on the tech project is going to have to have a technical edge and a strong understanding of the technologies used in the niche he is working in. However, by no means is this individual going to be the top tech expert in everything they touch and their project touches. If they were, the dollars they could command would be outrageous. That can’t even be expected of the tech lead. What that business analyst can do, however, is ask the right questions and a lot of them to get up to speed and help get the tech team and project manager on the right track to successfully deliver on the project. In order to successfully put together the right set of requirements necessary for the project, the business analyst is going to need to know as much as possible about the technology being used to deliver the tech solution as it affects design and development of the final project solution.

Summary / call for input

The bottom line is this – if the business analyst is going to find success for the project, they must ask questions throughout the engagement. Yes, there will be times when they are going to be expected to make key decisions on their own, quickly, without the time or ability to ask many, or even any questions because the information just may not exist. There may not be any availability during the given decision window of any stakeholders or available experts who have information or answers. In these cases, they move forward without asking questions. But these are hopefully the rare occurrences on big projects and the best case scenario is realized where the business analyst does have ample time to ask the right questions and ample resources to ask those questions of and to.

Readers – what is your take on this? Are you a business analyst who asks lots of questions? Can any BA really move through the business process and requirements definition phase without almost constantly asking questions? I’ve worked side by side and very closely with some of the best business analysts around during the understanding and defining of customer business processes and I’ve helped them through the requirements definition process and it is usually almost a never ending string of questions. Hopefully this is a very organized phase when it’s an open discussion of business analyst questions and project client answers so that that the requirements document can be put together containing very complete, detailed, complex requirements for the intended solution. Questions = information = project win.

The Most Important Soft Skills for Business Analysts

Written by Brad Egeland on August 7, 2018. Posted in Articles.

The definition of soft skills is “personal attributes that enable someone to interact effectively and harmoniously with other people.”

So when we look at the soft skills that a business analyst will need in order to have great project impact and success, we are looking at those personal attributes that help the BA individual work effectively with the project manager, project team, project customer, and all stakeholders involved so as to realize the greatest possible project successes on a regular basis. Yes, easier said than analyzed, but let’s give it a try. My list is below, but please be thinking of your own list if you are a business analyst, project manager or regular project team member who works with business analysts on an ongoing basis…

Quick learner.

The excellent business analyst must be a fast learner. Every client is different with different business processes and subject matter experts (SMEs) and different end users. No two implementations are ever going to be exactly the same no matter how similar they appear on paper. So the business analyst who can quickly understand the customer needs and environment will have the easiest time during the difficult requirements definition time because that process needs to be executed with the end rollout in mind.

Strong communicator.

The awesome business analyst needs to have the communication skills and abilities to keep an entire team and boatload of stakeholders up to date and on the same page throughout the project engagement. Yes, communication is Job One for the project manager in my book, but it is as well for the business’s analyst assigned to the project.

Confident decision maker.

The business analyst is not usually going to be the primary decision maker – at least on paper – for the project. However, in reality, they will often be making on the spot decisions – important ones that have significant project impact potential… often with relationship to scope and requirements.

Organized leader.

There is little doubt that the project manager is the overall leader of the project. At least in title that needs to be true. Behind the scenes and on a daily basis the true leader and most frequent communicator and customer interface may, indeed, be an excellent, experienced business analyst. Much will be expected of the business analyst – especially on complex long-term technical projects such as making key tech-related and business process related decisions, scope and requirements decisions, and information and task dissemination at the team member level, to name a few. So, the business analyst essentially goes far beyond a project manager <==> tech team liaison; they are also almost a co-leader of the project. To be that individual and effectively fulfill that role and need, they will need to be a confident and organized leader in the engagement and of human resources.

Meeting Facilitator.

Communication is the most important factor on any project – whether that is the project manager or the business analyst. So, let’s call it the most important responsibility for both roles. And meetings are not only a form of communication; they are a way to communicate with many key stakeholders at once to make information transfer happen quickly and to get decisions made on the spot. Planning, preparing, executing and following up on meetings and discussions is the key to proper and accurate communication, and it is something that the business analyst must excel at.

Master motivator.

Coach, mentor, motivator. You’d like to think that paid professionals don’t need motivated, but sometimes they do. And the business analyst is often going to need to be that person because on a daily basis they are working right along side the tech team and everyone doing the real work on the project as many a customer like to call it. Keeping the team – and even the client – motivated is a top priority.

Daily influencer.

I don’t want to use the terms “manipulator” or “manipulation,” so I will stick to “influencer.” The business analyst’s ability to affect project decisions, task progress, resource staffing and overall project direction is important to project success. No one is involved so heavily on a daily basis with many different project team members on both sides of the engagement and therefore will be in a position to influence stakeholders, decisions and next steps more than any other individual on the project – including the project manager.

Conflict resolution.

Conflict doesn’t always involve physical blows to the head… thankfully. All team members have a responsibility to the project to maintain clear and level heads so progress and success can happen. The last thing any customer needs to see is a less than a well-oiled delivery machine with all project team members working together and collaboratively in excellence toward a successful project end solution. The business analyst with great conflict management skills will recognize problems before they become too big to enact mitigating techniques to try to stifle the conflict before it becomes too impactive to the project. That likely would include some discussions with the involved parties individually and as a group, suggesting team member replacement if necessary, and disciplinary action, if needed.

Negotiator extraordinaire.

Many project team members – including many project managers – gravely dislike the process of negotiation and may try to avoid it at all costs. Most project tasks are planned, and budgets are set in stone… sure… but in reality, there are many points in the project where there is some give and take on the requirements and scope for the project. It may be as small as two fields on an accounting interface screen, or it may be as major as moving phases of a $10 million project around to accommodate immediately needed functionality. Whatever the scenario is, the business analyst is going to need to be a master negotiator. Why? Because on a daily basis that role is the one that will be interfacing the most with the delivery team and with the project sponsor and end-user community. That’s where quick requests will happen, where fast decisions will have to be made and where deep knowledge of the project and processes affected will have to already be in place when those fast decisions are necessary.

Summary / call for input

Business analysts play a key role in projects they are assigned to. They are constantly interacting with the project manager, project team, and project customer while maintaining a level of excellence in performance and communication for each of these. Certain key soft skills among the best business analyst make that happen on complex projects where performance excellence is necessary for a successful project conclusion and satisfied project client and end-user community.

Readers – what’s your take on the key soft skills for a business analyst? What does the experienced business analyst need to succeed on an ongoing basis… the personal skill tools and characteristics to perform at a high level.