Author: Brad Egeland

6 Things the Business Analyst Needs to Know at the Start of the Project

Written by Brad Egeland on July 5, 2016. Posted in Articles.

The skilled, experienced technical business analyst plays a critical role on the project as the main liaison between the project manager and the technical project team members. Not only that, they are often the “interpreter” for the project customer so what they need to be ready for at the beginning of the project is both critical and varied.

I’ve outlined here what I feel are the 6 most critical things that the business analyst needs to know or find out at the beginning of each technical project. Not always in detail – that may not be possible. But at least in as much detail as is possible. Let’s examine and discuss.

Related Article: 5 Things Your Project Customer Assumes You Know

Is the tech team ready?

This can mean a lot of things, but what I’m focusing on is this; is the team fully assigned and ready to go when needed?

I realize that this is more the call of the project manager as it is usually that individual’s responsibility to see to it that their team is assigned and ready when needed. But since the business analyst’s key role is to liaison with that team, then they are also involved in that process. The business analyst needs to assist the project manager in making sure that the right team members are available when needed on the project. Preferably not too early but certainly not too late.

Are they technically equipped for this engagement?

The technical project is going to need a particular mix of technical talent to get the job done. As the key tech liaison with the technical project team, the project manager is going to rely heavily on the business analyst’s assessment of the technical capabilities of the assigned project tech team. Do we have the right talent? Do they understand the chosen technology? Does anyone on the team need training to get up to speed? The business analyst needs to assess this and aid the project manager in making these things happen so that the project can move forward.

What state are the requirements in right now?

How well are the business processes and project requirements defined coming into the engagement? Many clients will come into an engagement saying they’ve already defined the requirements – hoping to keep costs low. However, 99.9% of the time you’ll find that they are way off in their assessment of requirements “completeness.” Requirements need to be detailed, complex, and very complete. They are basically the basis for all work going forward. The project manager needs to assess the requirements status and plan the project schedule accordingly, but the technical business analyst will be able to give a much better indication of the state of the requirements and how much more effort will likely be needed to get the requirements fully documented and signed off.

Does the customer have training needs?

It’s a technical implementation and requirements need to be completed with the customer’s input and eventually the customer will need to be leading the way in user acceptance testing. Is there any training – on the technology being implemented or on the customer product that is being configured and implemented – that the project client needs in order to complete the business process review and the requirements definition process successfully? After all, no client can really help the delivery team document requirements if they don’t understand the solution. I’ve found on many occasions that customer training is needed and that changes the project budget and timeline. But it is far better to assess that and make that correction up front rather than later in the project.

Do we likely have the competence to implement the necessary technical solution?

Can the team pull this project off technically? Can the organization? Sometimes a project is just not the right fit, no matter what a sales or account manager who signed the deal says. And the best time to make that call – rather than fail miserably – is at the beginning of the project before any real work starts and any real budget gets chewed up. Sometimes it’s just a tight fit, and some training may need to happen. That’s ok as long as it doesn’t hurt the timeline and the delivery organization takes on that cost if it wasn’t in the original scope of the project. However, sometimes the fit is never going to happen, and that tough call must be made. Once this is realized, talk it over with sales and senior management before throwing in the towel as you want to not only do it right, you want to make sure you’ve exhausted all options before you raise the white flag and surrender. Let senior management make that call and break the news to the customer…they approved the project in the first place.

Does the schedule seem doable? Most schedules are pretty tight. And after an early assessment of the project, the team, any training needs and the technology needed for the solution, the business analyst should be able to make a fairly reasonable – and accurate – call as to whether or not the initial project schedule seems doable. What you need to know from the outset is this; can you win on this project with this schedule – and with this budget? Is it possible or will it be impossible? You may not be able to make that call, but you likely can once you know the above information. At least with some reasonable degree of confidence. If you need more time for the project, the best time to negotiate for that is at the beginning. Later on, it will just look like you’re failing.

Summary / call for input

I’m not saying the business analyst needs to know everything…just like there is no way the project manager can definitely say everything is in order on the project at any given time. However, this list of six key project elements are usually well within the technical business analyst’s knowledge base, and they can make at least a good call on where the delivery team stands on its ability to implement the right solution for the project client. And really, that is what we need to know before we get started because it will affect everything going forward -the timeline, the budget, etc.

What about our readers? What would you add to this list? What would you change about it? Business analysts, what do you see that is missing or that you don’t agree with? Please respond and discuss.

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.

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?

The Business Analyst’s Role in Project Closeout

Written by Brad Egeland on March 21, 2016. Posted in Articles. 1 Comment on The Business Analyst’s Role in Project Closeout

I’ve written about project closeout before and the need to plan well in advance for a complete and, hopefully issue-free, project rollout and closure. Planning well does not guarantee success.

If you have dotted all of your “I”s, crossed all of your “T”s, the requirements for the project have been followed and incorporated into the end solution, and user acceptance testing went off successfully, then you should be about as good to go as you possibly can be.

That said, there are some things the project manager, business analyst and entire team should be planning to do and running through especially as the project is winding down.

These are, at a minimum (but not limited to):

Reviewing all project financials
Re-reviewing user acceptance test (UAT) results
Checking all project milestones
Making sure all training has been successfully completed
Conducting and documenting a lessons learned session
Making sure all appropriate deliverable, UAT, and project sign-offs / approvals are in place

Where does the business analyst fit in?

{module ad 300×100 Large mobile}

We have a good list of some high-level project closeout checklist items to use to make sure the project work is complete, approved by the project client, and ready to be rolled out to the customer’s end user community. But what about the business analyst? They have intimate knowledge of the solution, the technical project team, the requirements, the customer and the customer’s end user community. They are that technical team and customer liaison and will be involved in everything associated with the project closeout planning, assurance, and rollout activities.

Let’s examine what roles in specific areas of project closeout activities that will logically be played by the business analyst on a technical project. As you read through these, please be thinking of ones not mentioned here – especially if you have experience with specific issues and concepts not mentioned – and be prepared to comment and share your own thoughts and experiences. For now, mine are:

Early planning for project closeout. This role should fall mainly to the project manager as it is a planning activity and will tie in heavily to the project schedule – which is under the primary charge of the project manager. But in terms of many of the detailed project tasks that must happen and what timing and effort will go into each, much of that input can and should come from the business analyst as their expertise and experience are vital to the proper estimation of the level of efforts for many of these tasks.

User acceptance testing. Here is an area where the business analyst will definitely shine and is crucial to project and client testing success. Don’t do the test cases and test scenarios for the project customer – that is a conflict of interest. But the project customer is nearly always weak in this area, and a poorly tested technical solution means the delivery team has a good chance of rolling out a final solution that doesn’t fully meet the customer’s end user community’s needs. That’s not good. So the good business analyst is critical to successful user acceptance testing. That individual can help the customer develop test cases and test scenarios, help walk them through UAT – figuratively holding their hand along the way as needed and help to gain that crucial UAT sign off / approval from the customer. Essentially, that becomes almost a sign off on the entire solution as the rollout is being prepared for because that is what they are testing. This one role is the key to success.

Milestone and deliverable review. Because the business analyst is involved to a high degree in all project milestones, and likely the production, review, delivery and sign off of all project deliverables, it makes great sense that this individual will be involved in the review and validation of completion and sign off of all project milestones and deliverables. This basically involves running through the project schedule and documentation file with the project manager – and maybe the full team – to ensure that all tasks were completed, all deliverables went to the customer and received signoff, and likely that all deliverables were paid for. Through my experience, however, the financial aspect is usually the sole responsibility of the project manager.

Conducting lessons learned. The lessons learned session is important to gaining insight into what pleased the project customer and what they perceived as not going as well as it should. While the project manager should facilitate this session, the business analyst will probably be the main commentator and communicator with the project customer team when specific tasks and activities of the project are discussed.

Rolling out the solution to the project client and end user community. Finally, the actual project implementation or rollout will be primarily led by the project manager and business analyst. The BA will mainly be a technical liaison – running down any issues, working the project technical team in issue resolution, and solution handoff. The business analyst did this during requirements, design and configuration of the project solution, and most assuredly they will be leading this effort on the ground during project implementation or rollout to the end user community.

Summary / call for input

I’ve said it many times, and I will say it again – some companies want to combine the project manager and business analyst role or the business analyst and tech lead role on technical projects. I think a good business analyst – performing the common duties of the business analyst – is too critical to the project’s success to be combined with any other role. Doing so only for very small projects or for very cash-strapped organizations may be an option, but it is not a good long-term plan on all projects. because the business analyst has usually played such a key role throughout the engagement, and as the project is winding down, their involvement in many aspects of that project close out is critical to the project’s overall successful ending. And, thus, customer and end user satisfaction, both of which are keys to success.

How about your thoughts? What do you consider to be key roles of the business analyst in the close out of the technical project – or any project for that matter? Please share your thoughts on this list and your additions and let’s discuss.

10 Characteristics of an Awesome Business Analyst

Written by Brad Egeland on March 1, 2016. Posted in Articles. 2 Comments on 10 Characteristics of an Awesome Business Analyst

Does your organization handle large, complex technical projects? Do you have diversely skilled project teams assigned to those projects? How about overloaded project managers? Are they juggling several projects at once?

This sounds like every organization I’ve managed projects in and every company that I’ve consulted for along the way.

If this is your organization, too, then you likely need the best of the best in terms of a business analyst on each project being led and executed on for the project customers your organization is serving.

If you do need the “best of the best”, then what skills or characteristics are you looking for? What defines the best for your organization’s project needs?

While BAs are not project managers, the most successful BAs manage the entire business analysis effort. This means that the BA is proactive and dependency-aware. It also means they manage themselves well, the stay on track with respect to commitments and deadlines, and can handle task delegation, decision-making, and issue management as needed on the project.

I’ve thought about the overall skill set and characteristics needed to conduct this role efficiently and productively. Coupled it with my experience leading projects, working in combined project manager and business analyst roles I’ve come up with my list of ten characteristics of an awesome business analyst.

{module ad 300×100 Large mobile}

As you are reading through these, please be thinking of your own personal experiences and comment with your additions to this list.

Great customer interface. The great business analyst is a critical liaison between the project manager and the technical team. This person is often the driving force behind the accurate, complete, and detailed documentation of the final project requirements. Why? Because the organizational to tech cross-over ability and skills that many project managers will lack must be handled in this role. And they help the tech lead interpret those functional design ideas into technical design specifications for the design and development work on complex technical solutions.

Subject matter expert. The skilled business analyst is vital in their project team role as a subject matter expert. This helps them to work with the client to document accurate business processes that are then used to create detailed, complete, and accurate project requirements.

The business analyst’s technical knowledge coupled with his understanding of the design process and the likely end solution makes him an invaluable resource for the project manager the project team and the project client.

Good technical cross-over. The very valuable business analyst has a diverse amount of technical knowledge. Not necessarily tech lead or developer knowledge, though that is a plus, but rather a very good technical acumen that gels with the project management-type organizational skills and knowledge they also likely possess.

Can project manage it when needed. The indispensable business analyst can and often acts in the role of project manager, both when the project manager may be tied up on another project and also when interfacing with the team and client and a decision needs to be made if the project manager isn’t currently available.

Critical attention to detail. Detail-oriented focus is needed by the business analyst on the project for a variety of reasons: to assist the project manager and fill in there as needed, to work closely with the customer sponsor and team and the project team to define and document requirements, and to help track and resolve issues throughout the engagement.

Skilled communicator. I’ve often said that communication is Job One for the project manager. However, communication skills are possibly the most important characteristic of the awesome business analyst if for no other reason than the vast responsibilities this position has on the project and with the team and customer.

Miscommunication can lead to so many problems on the project. The awesome business analyst ends up interfacing with all stakeholders, making accurate and thorough communication necessary.

Facilitation skills. The business analyst is going to be required to facilitate many meetings and sessions during the project such as periodically leading the team meetings and formal project status meetings for the project manager and then requirements meetings with the customer as well as design sessions with the technical project team.

Experienced critical thinker. Business analysts are responsible for evaluating multiple options before helping a team settle on a solution. While discovering the problem to be solved, business analysts must listen to stakeholder needs but also critically consider those needs and ask probing questions until the real need is surfaced and understood. This is what makes critical thinking and evaluation skills important for the business analyst on the project.

Skilled with PM and organizational tools. The business analyst needs to have a good command of the use of various project management related tools such as project scheduling software, basic tools like Word, Excel and PowerPoint, and others that might be needed such as task management software, bug tracking software, risk management software, file management software, and even modeling tools like Visio, etc.

Conflict resolution. From time to time conflicts can arise. I’m not talking about fisticuffs…at least I hope not. But disagreements among technical team members or with members of the customer’s staff can arise. The skilled BA will recognize this quickly and work with both sides to come to a mutual agreement. Patience is also a virtue because any conflict resolution requires patience and understanding. And good listening skills.

Summary / call for input

The business analyst isn’t necessarily the leader on the project, but his role may be the most diverse and sometimes the most critically necessary for project success. The project manager will serve as the overall communicator and decision maker on the project, but the business analyst will likely have an even closer customer facing role than the project manager, meaning this position may be the most valuable in helping ensure customer satisfaction and completeness and acceptance of project work performed by the project team.

How about our readers? If you’re a business analyst, what do you think about this list? What would you add to or remove from this list? What are your top 3 or top 5 characteristics for a valuable business analyst? Some organizations – often smaller organizations – may only hire a project manager or business analyst to handle both roles. Have you worked with such an organization and did you find it to be successful?