Tag: Business Analysis

5 Things Business Analysts Wish Their Project Manager Knew

Written by Brad Egeland on June 8, 2016. Posted in Articles. 1 Comment on 5 Things Business Analysts Wish Their Project Manager Knew

There is no doubt about it if there is a project manager assigned to the project – and surveys show that about 85% of the time there is – then they are in charge. The other 15% of the time the business analyst or possibly even a technical lead or other project leadership position may be running the show. But it is usually the project manager’s job to run the project.

Communication is the PM’s key responsibility, and the rest revolves around that. Business to tech liaison is the business analyst’s key role on most technical projects and the rest of their tasks pretty much revolve around that one key concept. It goes without saying that project success relies heavily on how well they manage to handle their separate tasks while interacting effectively with each other throughout the project engagement.

Related Article: Project Manager vs Business Analyst

That said, the business analyst plays a huge role – a very key role – in every project’s success. I think it is essential that a business analyst is assigned to every project of any mentionable size and technical nature.

But the project manager doesn’t know everything, nor can they read the business analyst’s mind. So, for this article, I’m going to try to do something about that and read the mind of a business analyst and give you a list of five things that business analysts wish their project manager knew about the business analyst’s role and responsibilities are on the project.

They can handle it, so step aside.

The project liaison position is theirs to oversee. They are the go-between the project manager and the technical team. That, of course, doesn’t mean the project manager can’t interact with the technical team. But for the purpose of the down and dirty work of translating business process into design, that work is the business analyst’s to perform in conjunction with the tech lead and technical development team. The project manager has enough project administration work today.

The customer likely feels more comfortable working with them.

No offense, project managers. You definitely have your job to do. And it is critical in nature. But the business analyst also has their job to do, and that starts with immediately working with the customer on understanding their business processes and how to interpret those into detailed, complex project requirements. Let them do that – unless they also need your help doing it – and the customer will be much happier.

Some tasks shouldn’t cost $300 per hour.

More on the “overlap” concept of project manager and business analyst duties. Sometimes these two entities need to work very closely together. Sometimes you only need one of them. Often times they are the most expensive resource on the project – charging out to the project client at $150 – $200 or more per hour. Many of those project tasks don’t require $300 per hour of effort, and you’ll make the project budget go much further if you don’t allow that. Plus, your client satisfaction will be much higher the longer you make that project budget last.

Divide and conquer project tasks whenever possible. Don’t needlessly double up the effort and expense to the client.

They really are there to work closely with the tech team.

Hopefully the business analyst is available to the project manager and entire team throughout the entire engagement. I really feel that a good business analyst is tantamount to success on a project. But what they aren’t there for is to be a “helper” for the project manager. They have many key tasks to take care of on their own, and rarely is project manager “helper” one of those tasks or role titles.

There are those projects where the project manager or the business analyst can and do fill both of these roles, but not usually on large, complex, highly technical and / or highly visible projects. Those very detailed projects require a separation of roles. And on a technical project, much of the business analyst’s time is spent working closely with the technical lead on the project and the rest of the technical team.

The project manager’s help is always welcome.

Both the project manager and business analyst are likely slammed with work on a big, complex, technical project. And both may have other projects they are leading or contributing to. But even though you should avoid doubling effort and expense needlessly on the project, the business analyst will still welcome the project manager’s input and assistance on many or most tasks when the PM is available. And the reverse is true as well. Just use good judgement in how much you double effort and how much of that gets charged to the project client. That budget oversight responsibility falls squarely on the project manager’s shoulders, so watch the budget carefully and you should be ok.

Summary / call for input

Good project managers and business analysts – especially if they’ve worked together before – can really gel on the big projects. I’m not talking about completing each other’s sentences – that would be a little creepy though I’ve seen it and been a part of it on one critical project. But how well the project manager and business analyst work together and with the rest of the team can definitely spell success or failure on the project. That relationship is probably the most critical one on the engagement. But the project manager doesn’t always know what the business analyst wants, needs or is thinking, so spell it out. Communication, after all, is critical to project success.

How about our readers? What are your thoughts on the project manager / business analyst roles? If you’re a business analyst, what are the top five things you wish your project manager knew without being reminded or told? Please share and discuss.

Strategy Spotlight: Benchmarking & Baselining Your Organization in 6 Easy Steps

Written by Richard Lannon on June 7, 2016. Posted in Articles. 2 Comments on Strategy Spotlight: Benchmarking & Baselining Your Organization in 6 Easy Steps

You cannot conduct strategic business analysis or project management without benchmarking and creating a baseline. That is a fact.

I have seen times where executives and professionals skip this part of the planning process, thinking that they have all the information they need to document the current state. I have seen a lot of incidences where these people have been wrong and engage in a form of blame-storming when something was missed.

When working on a project, whether a pre-initiative or post-agreed, you need to focus on your benchmark and create a baseline to ensure you are clear about your present situation. A benchmark is a standard point of reference within your industry against which things may be compared or assessed. A baseline is the starting point used to compare your historical performance. Both are connected in the world of business analysis, sometimes interchangeable. The definition can change based on context.

Benchmarking became an important part of business performance management and a key input into financial analysis and business process improvement. It is also a powerful tool in change and transformation analysis forcing executives to look at the reality of the business through the facts. This is a practice that can become extremely uncomfortable for some people at times.

When I was thinking about this blog, I reviewed some of the steps that I have taken to benchmark a client’s internal and external situations. I realized that for me, benchmarking and baselining followed a standard 6 steps of activities.

1. Preparation

You will often hear me say preparation is the key to the success of any engagement. That is the truth in facilitation and in benchmarking activities. In this case, preparation has to do with your initial interviews and discussions with the leadership team to help you understand where their thoughts are at present, focusing on finding out ‘what, why this and why now.’ As part of this preparation, you need to know to what level the stakeholder is invested in the situation. Is it an emotional connection, being dictated from elsewhere or are they just stepping through the steps? This is all important to know.

2. Research

Getting the information you need is all about data collection. Information can be considered primary or secondary. Primary information is an account of the event from an original source. Secondary information is an interpretation of the account of the event.
There are many means of getting the information you need. I often use a three stage questionnaire process with the primary information holders and pre and post interviews to get a present state understanding for benchmarking. I expand my understanding by adding documentation reviews from inside and outside the organization.

3. Analysis

This is a key part of the pre-planning process often requiring information integration, leveling data and checking the sources and facts. You may need to normalize the data to ensure that a direct comparison is possible for operational subjects and issues. The analysis needs to provide comparisons, look at the gaps, cover all strengths and weaknesses, and be improvement focused. By this point you should have a clear state of the company, the project, the industry or application.

4. Presenting

This could be called reporting. It is just a matter of what the deliverable is. Prior to doing any planning type session (workshop, review, discussion), I do a summary of findings. This summary is laid out in such a way that the high-level stakeholders get a story of their present situation and is used for future planning. It is often delivered as a high-level, point form, executive summary with the supporting summary of findings behind it. It is not an extensive report – only a summary of findings. There is a difference. Accompanying a summary of findings might be a 6-slide deck using images to capture the data components.

5. Lessons

I have always liked the expression “forewarned is forearmed”. I think that is what lessons learned should be about, especially when we are doing benchmarking.

During the process, the business analyst should have gotten a clear picture of what I call the “truth”. The issues at play are known, and you should be able to pre-determine how things are going to play out and therefore plan more effectively. At a higher level, the best performing organizations share information and best practices for the benefit of all. If your baseline and benchmark are clear and honest, then you can start to focus on solutions and actions that need to be taken.

6. Actions

It is great to use the word “actions”, but it should not come before planning. In other words, “plan to act” with a well thought out implementation or action plan. This can only be done after the lessons have been accepted, integrated into the key stakeholders thinking (planning team) and the lessons learned can feed into the planning process.

The focus here is what you need to do to go forward based on your benchmark and baseline for your organization with all the common constraints. Dialogue should be forthcoming.

I can’t even remember the number of times that I have been part of benchmarking an organization or system through a combination of interviews, surveys, documentation, industry reviews, and workshop facilitation. I’ve participated in all of these activities just to get a clear picture of the state of things.

I do believe the process can be standardized and applied to any situation where getting clear on the present state is important and benchmarking to internal or external standards.

Developing good benchmarking and baselining skills is important. Chances are you will find yourself following a very similar process each time. I would encourage you to document your approach and share it. It is the place where good business analysis and planning starts. I hope this helps.

And remember:

Be your best, invest in the success of others, and make your journey count.

Richard

Is a Multi-tiered BA Certification Program the Way to Go?

Written by Laura Paton on May 26, 2016. Posted in Articles. 1 Comment on Is a Multi-tiered BA Certification Program the Way to Go?

For anyone waiting for the unveiling of the new certification program from International Institute of Business Analysis™ (IIBA®), I have been wondering whether such changes will be helpful for organizations and the practitioner community as a whole.

The one thing I have learned over the years from the community was that the certification process, including how one applies and qualifies for these exams needs to be more straightforward and avoid complexity at all levels. Having been proposed for some time now, we still don’t know enough about the changes being made to the program to form an opinion – or do we?

Here are a few factors I have been thinking about with regards to these changes. I would love to hear what you have been pondering. In this post, I am simply putting the questions out to the community for consideration. I form no opinion, but as a current Certified Business Analysis ProfessionalTM (CBAP®) I am really interested in knowing what other certification holders are thinking.

1. Level 1 – Today knowledge based certificates in business analysis are plentiful as a large number of training providers already offer BA certificates. Will this new Tier 1 certification be a differentiator in the industry? Several years ago IIBA spoke with EEPs about providing a jointly branded BA certificate, and for many really good reasons Endorsed Education Providers (EEPs) did not want IIBA crossing the line into the training space. Has enough changed here? Do employers and practitioners believe Level 1 recognition from IIBA which assesses general BA knowledge (no experience) is more significant than a certificate from an EEP whose sole focus is on training?

2. Level 2 – The market for the Certification of Competency in Business AnalysisTM (CCBA®) has never really taken off, as of today after 5 years, there are only 850 CCBA holders. Are the proposed changes to scenario-based exam questions significant enough here to help IIBA grow this certification or are there other issues with this certification that if addressed would help the viability of the CCBA®?

3. Level 3 – The CBAP® used to be the gold standard, and those of us who acquired the CBAP® felt like we were demonstrating our senior level experience to employers. After all, the CBAP® has always been an experienced based exam. In the early years, many of us struggled to find employers who found the certification as a differentiator or who deemed it mandatory for employment. Over the years some awareness has taken place; although still not as widespread as the PMP.

CBAP® recipients felt the certification demonstrated their commitment to the profession and identified themselves as senior practitioners. With the proposed changes, CBAPs will no longer be the top tier. Are CBAPs ok with this? Do CBAPs feel an urge to run out and spend more time and money to get back on the top tier of the ladder? Anyone feeling like their credential is less attractive or valuable to you, to your employers or to the BA community? On the other hand, are the CBAPs excited about pursuing this next higher level certification?

4. Level 4 – Lastly, the new level geared to thought leaders. It has always been the case that thought leaders are recognized in the community by their contributions. Their credibility is achieved through the engagements they are completing within organizations, with the research they are performing, the articles, books, and other products and services they provide the community at large. If you look today, many very influential, experienced, top-notch thought leaders do not have a credential nor do they need it because they are already well-known in the industry for the work they are doing for all us. I am very curious to hear from the community whether our thought leaders require a certification to be recognized or acknowledged as a thought leader? If organizations are looking for thought leaders to be validated through such a process, is such a model scalable since level 4 will require an assessment?

Lastly, I want to ask about the idea of moving to a competency-based framework for certification. Back in the day when Angela Wick and her team developed the Competency Model, it was and still is an amazing product. The team spent countless hours building a framework to help articulate what skills and competencies define a novice business analyst from an expert business analyst, but it was a tool that must be applied along with a lot of other factors to be able to tell an accurate story of competency.

For example, if you are a business analyst in an organization and are not working on large, complex, transformational projects you may never leverage a lot of the skills in the upper categories of the competency framework. For your organization, for the role you have been hired into, does that make you less competent? What about the business analysts in financial institutions responsible for bringing their clients online with a standardized financial service, where each client is a new project, but the projects have little variation to them? These business analysts become very proficient working in their organization as a business analyst/implementation analyst without needing to leverage many of the top tier skills in the framework. Does this mean they are less valuable or less competent to their organization because their projects are consistent in type and size?

In my opinion, the role of the business analyst is defined by the organization based on a multitude of factors that really can’t be standardized across industries because there are an infinite number of factors that apply. To make an assessment of competency, consultants have to work with the organization to conduct interviews, look at templates, watch processes and practices first hand, and understand the project environment to assess competency within context. Knowing this ‘as-is’ state is very critical before conducting a gap-analysis to assess what competencies are missing. I have performed competency assessments for years in this fashion. My question here for the community is could a 3rd party working outside the walls of your organization assess competency without having this ‘as-is’ picture? Is this approach old school and is this 4 tier approach answering some newer needs organizations have today about the competency of their BA resources?

Lastly, I myself am interested in understanding the research completed to support a 4 tier certification. Typically I have seen a role delineation study conducted to provide the insight to align and structure a product like certification. I am not proposing it has not been done, but simply asking whether anyone knows. Since I don’t know, I am really interested in raising some dialogue in the community to hear your likes/dislikes to the pending 4 tier structure.

Please share your thoughts and provide different perspectives.

5 Challenges for the Business Analyst on a Hybrid Project

Written by Lavinia Mihaela Dinca on May 19, 2016. Posted in Articles.

Agile has become a common methodology used in many projects, and it’s being used more often. Experts agree that the future is not agile or another methodology, waterfall, but a hybrid of the two.¹

Hybrid projects combine methodologies in an effort to use the strengths of both and minimize each of their shortcomings. Implementing a successful hybrid project means needing to have experience with both.

I will give two examples where a hybrid approach will work.

A large project with both hardware and software components can use a hybrid methodology: waterfall for the hardware component and agile for the software component.

Related Article: 5 Lessons From Working With Agile & Waterfall

A second example is a more challenging one: a complex software project where the GUI is created using agile and waterfall is used for feature development.

Hybrid projects strain most of the team members, but it affects the business analysis team more because they have to keep track of everything being developed.

The hybrid project examples from above may be regarded as the separation of church and state. Using waterfall on a hardware part and agile on software part is not difficult, and most likely the BA teams will be separate anyway. “True” hybrid projects are rare, but they will apparently become a reality. By “true” hybrid project I mean a software project where different features are developed using both methodologies at the same time.

In my opinion, there are 5 main challenges a business analyst faces working on a “true” hybrid project:

1. What goes where

Knowing which part of the project will be done using waterfall and which using agile can be complicated. Waterfall tasks can be hardware implementation, application security features, enterprise business architecture, and critical core features. The agile tasks might be GUI design or business features which can change.

Determining what goes where should be set from the beginning of the project. Problems may arise later on if this isn’t done. When issues appear during the project, they should be discussed with the project manager and any other senior members of the team and an informed decision made about which feature goes where. It shouldn’t only be up to the business analyst to decide.

2. Requirements prioritization and integration

In a hybrid project, feature prioritization may be extremely difficult. The business analyst has to take into account which features will be developed using waterfall, meaning they will be delivered towards the end of the project.
Some features developed with agile might be dependent on the previous ones, and they should be rescheduled toward the end of the project if the prior deliverable is developed in waterfall.

Requirements integration is also challenging because of the same issue: some features will be delivered at the end, others before.

3. Requirements description and documentation

Requirements description is different in level of detail in both methodologies. On a hybrid project, the business analyst must be prepared to do both: requirements for the waterfall part and requirements for the agile one. The problem that might arise is the gap in documentation. Some features will be more detailed (the waterfall ones) and some more high-level (the agile ones).

I think that the most discrepancy will be in the testing documentation because in waterfall the test cases are developed in the analysis phase for all the features. In agile, the test cases are developed for every use case, in every iteration. This means that the application testing will be very difficult overall.

4. Trace / Identify missing requirements

Tracing requirements and, most importantly, identifying missing ones will be challenging. A common mistake is assuming that a certain feature will be developed in waterfall, meaning later on in the project, and business analysts might move on with other tasks.

Another problem is identifying missing features due to fragmented analysis. Some requirements were taken in the waterfall phase and others during agile sprints. Naturally some requirements might be overlooked and never developed. A common requirements matrix must be maintained regardless of the methodology used to develop the feature and business analysts must be involved in both stages of the project – and not have business analysts for agile and business analysts for waterfall.

5. Communication and collaboration

In any project, communication is very important, but in a hybrid one, it’s the difference between failure or success. The BA’s role must be regarded more as a facilitator for the team. The BAs will have an understanding of all the features being developed project-wide, regardless of the methodology, and they will be in a unique position to mediate misunderstandings, provide clarifications, and even help the team understand why a certain feature should be developed using certain methodology.
Personally, I think that “true” hybrid projects are still a long way to go and that most of the hybrid projects will isolate the agile and waterfall methodologies. I think this situation will last for a few years because there are still companies struggling with agile. Companies implementing agile projects still struggle to understand that a business analyst has an important role to play in an agile project and that this role is not obsolete.

Do you think it is feasible to do software development using both methodologies at the same time?

Do you agree the future will be hybrid? What items would you add or remove from the list?

¹ http://www.bridging-the-gap.com/traditional-vs-agile-the-future-is-hybrid/

5 Reasons Why You Need a Business Analyst Before Project Kickoff

Written by Brad Egeland on May 11, 2016. Posted in Articles. 1 Comment on 5 Reasons Why You Need a Business Analyst Before Project Kickoff

In a perfect project world, the cost of the project and the resources you use on it wouldn’t be an issue and the best resources could be available to the project 24/7 from the beginning. Oh, and they wouldn’t need sleep, and they would never get tired. In a perfect world – or at least some alternate universe.

But we don’t live in a perfect world and project resources do cost money – a lot of money. And, unfortunately, they actually do need sleep.

So in this imperfect world, we really don’t want the entire project team on board at kickoff time because there isn’t anything for all of them to do yet. They would likely end up charging time to the project budget that we don’t need. While we usually can’t get – or even want – the entire team assigned at kickoff, it can be extremely beneficial to have the business analyst assigned by that point. Why?

Here are my 5 reasons why assigning a business analyst at kickoff will help the project, the project customer, and the project manager.

1. Technical questions DO come up in the kickoff session.

Some technical questions need to go back to the project team AFTER kickoff and then handled via other communication with the project customer and his end users or subject matter experts (SMEs). And those I will cover later in this article. But some nearly always come up during the kickoff session that can be handled – and should be handled for the sake of forward progress – during this critical meeting. The project manager may be able to handle those, but the business analyst should be able to handle those and between the two some key decisions can be made – with the project customer and any SMEs present that will keep the discussion flowing rather than halt progress and create yet another issue “to be handled later.”

2. Next steps involve requirements, and the business analyst will play an integral role in the definition and documentation of requirements.

Usually, the next steps after the project kickoff session involve some discovery, some business process review, some AS-IS and TO-BE planning, and definitely the detailed project requirements definition and documentation. A business analyst who has been present in the statement of work (SOW) review, the draft project schedule preparation, and the discussions that happen at the project kickoff session will be that much farther ahead when both sides sit down to document real, complex, detailed requirements that the tech team will build technical design documents from and develop the solution from.

3. Prep includes the project schedule, and the business analyst can definitely add much value to the drafting of the initial schedule.

As I’ve stated, the drafting of the project schedule will happen prior to the project kickoff session. This project schedule likely won’t be reviewed in detail during the kickoff session, but it will be in the customer’s hands during that session and the more detail that goes into the schedule and the more that it makes sense, the more confident the project customer will be in the delivery team’s ability to roll out a quality end solution. And that first impression is always big. While I am always in favor of having a project manager who can fight his way out of a technical paper bag on his own, the business analyst is usually his superior technically, so his input to the draft project schedule that goes to the customer and helps drive the kickoff session discussions can be extremely beneficial.

4. There will be take away questions – having the business analyst present negates the potential for misinterpretation and miscommunication as those questions go to the tech members of the project team.

I’m not saying the project manager can’t handle this. I’ve handled this many times. But I’ve also led enough technical projects to know that if I have a business analyst sitting beside me, they are also representing the tech team that hasn’t been assigned yet, and their brain is already thinking that way while I’m still focusing on organization and next steps. Having the business analyst present during kickoff lessens the possibility of any misinterpretation or miscommunication of those questions that need to be taken to the tech project team.

5. The business analyst can add more precision to the estimates that go into the draft project schedule.

The draft project schedule that is taken to the project kickoff session is really more than a draft schedule. It is the active, living, breathing schedule at that point and should only need some minor tweaking as the kickoff session comes to a close. That being the case, having the business analyst assigned and putting that together with the project manager means that effort estimates that go into that schedule will be that much more accurate. As a project manager, consultant, and former developer, I consider myself a very good estimator of project task effort – yes, even all the complex development tasks on technical projects. But the business analyst usually – at least on my projects – has served to be the liaison between the project manager and tech team and they are usually even just a bit better at providing detailed, fairly accurate estimates than I can. And more accuracy and realism is always good as you head into the kickoff session and beyond.

Summary / call for input

The bottom line is this. In my opinion kickoff sessions and the project, in general, just go better if the business analyst is assigned as quickly as possible. Unlike the tech team members who really can’t do much until design starts, the business analyst can prove to be an invaluable resource from Day One as the project manager goes through the administrative work and planning to get the project kickoff session in place and the project schedule assembled.

What about our readers? What are your thoughts on the business analysts assignment to the project team and the timing of that assignment? What is your organization’s policy or does it depend on the project? What is your preference?