Author: Brad Egeland

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

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

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

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

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

Knows the material and technology.

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

Knows the tech staff.

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

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

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

Has connections in the organization.

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

Works well with the project leadership.

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

Summary / call for input

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

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

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

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

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

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

Customer interaction.

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

Being technical.

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

Tech documentation.

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

Being organized.

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

Handling project budget issues.

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

Leading meetings.

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

Understanding PM processes, practices and tools.

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

Summary / call for input

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

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

Working with the Demanding Project Customer

Written by Brad Egeland on September 20, 2016. Posted in Articles.

We, as business analysts, never have to deal with problematic or demanding project clients, right? Sure!

I’ve dealt with my fair share – a couple even just this month. And I’m sure the business analysis community out there who has to face project customers every day and hold their hands through lots of ongoing project activities have certainly had their share of demands and push backs that make them wonder why they even bothered to get out of bed that morning.

We can say that the customer comes first. For me, that is almost to a fault – meaning if I’m working on a project in an organization I will often go above and beyond to make the project customer happy even at the expense of direction from my PMO director, mainly because I’ve followed bad customer advice from PMO directors in the past only to watch two very large projects shutdown as a result.

Yes, hindsight is 20/20, and I am very cautious in following that type of direction that seems to conflict with my project client’s satisfaction and the project’s overall well-being.

That being said, what happens when you are filling the role of the business analyst and working closely with those difficult or demanding clients and your gut tells you not to proceed? What if the client wants us to jump through hoops just to maybe get their business. Or a hiring organization asks you to go through just one more process, or just one more test or just one more demonstration before they make their decision?

I’ve had that one happen before. You end up having so much time dedicated to the process already that, even though you want to call them up and say “I’m out!” you hesitate to do so because “It’s just one more round” and you’ve already put ‘x’ amount of effort into it.

I had some potential clients recently who wanted me to put on a mock project kickoff session for them as “just one more thing” before moving forward. I still haven’t heard anything from them. And I have a software vendor who has gone in circles for two years asking me for proposals and then we will start…and then nothing. False starts take time, waste time and mess with your mind and planning process. It’s hard to say “no more” but at some point, you just have to.

How do we handle these types of clients? Better yet, how do we recognize and dismiss them before we go crazy or put too much wasted time and effort into them? Because if there’s one thing I’ve found it’s this – you can’t turn a bad client into a good one. It will never happen. So if you’re gut says “no” early on…you should probably act on that.

Here are my top three signs of a bad, overly self-important client and how to respond.

1. Show me first with some free work and then I’ll decide.

They want something for free before they’ve ever paid you anything toward a project or a consulting engagement. Run away the other direction as fast as you can. If you already have a good resume and a good reputation and some proof of that, you don’t need to prove yourself any further. The three times I can recall in the past few years falling for this to try to get a consulting client on board it ended up being a complete waste of my time and it disrupted my productive thinking and schedule of what I was doing for good, paying clients. No more.

2. My way or the highway.

You’re the expert so you’ll have to be the judge on this one. But if you have specific experience, and you know that way won’t work, but they won’t listen, run the other way.

If you can’t convince them that their way is not the right way, then you probably should not take on the work.

Now, if they don’t seem to care about their money and understand VERY CLEARLY that you are waving flashing red lights in front of them and they still want to pay you to proceed, then maybe you should just go ahead and take their money. Just be careful when considering what this could do to your reputation. Are they going to announce you to the world as a failure if it fails, as you know it will? Make sure it’s worth it to you.

3. Why can’t you do that? OR the price is too high.

As the business analyst, you are often the liaison between the customer and the project manager – though the project manager should and does have their own major amount of customer facing time and responsibilities. You are often – and in some cases, always – the liaison between the customer and the technical project team. In fact, it can be a little dangerous letting the customer have too much face time with the development team. The development team can end up being too open to the “little” requests resulting in what is known as expensive “gold plating” of dev work above and beyond requirements and the budget.

So think of yourself as somewhat of a gatekeeper. Telling the customer “yes” and “no” on requested work and dealing with those “the price is too high” complaints or feedback responses. And maybe it is – for them. Don’t sell yourself too short. Discounts are fine. Taking less pay for a remote position when it is very worth it to you to do so is fine. Again, just be careful because once you’ve discounted, you won’t retain that client if you raise prices later. That’s why when I discount something for a client I make sure it’s still worth it to me per hour and I clearly write it into the agreement that they will continue to receive that rate as long as they maintain continuous – that’s the key word – service from me. If they leave and come back, then I can assess whether I want them back and at what price.

Summary / call for input

The business analyst has lots of “customer” responsibilities – likely even way beyond what is written into their job description or what is planned on each specific project engagement. But, the project wouldn’t flow nearly as well without you.

How about our readers? How do you deal with difficult project customers or problematic (or cheap) clients? Share some of your thoughts and possibly even horror stories and let’s discuss.

What if the Project Client Won’t Move Forward?

Written by Brad Egeland on September 7, 2016. Posted in Articles. 1 Comment on What if the Project Client Won’t Move Forward?

Business analysts – tell me this – have you ever worked with those project clients that you can’t seem to get out of the starting gate?

You seem to be in a perpetual starting mode, but the real project never seems to happen? Have you ever had projects that seemed to take forever to start and maybe never started?

As an independent consultant, I’ve had many clients seem like they were ready to go yesterday on projects…only to find myself six months later still discussing how we might get started. It’s frustrating; it takes time away from other projects we are managing or involved in and caters to clients who may really only be fishing for information from experts with little to no intent of ever starting a project.

How do we recognize these situations so we can somehow avoid them the next time they start to show these same signs? Or better yet, how do we help push them along into real projects? Let’s consider some possible concerns.

How can we more easily and quickly recognize these situations as they start to happen?

My quick answer is you don’t recognize it until it’s too late. And by too late I mean until you’ve spent some considerable email and phone time – and for larger, potential projects maybe even face to face time involving expensive travel. Yes, you may blow through a considerable amount of time and money and never get anything out of it. That’s the nature of project negotiation – it happens all the time. But avoiding it is almost impossible.

You don’t want to chase those project opportunities that are clearly outside of your scope of expertise. Your likelihood of success is low anyway. But if it looks like a good match then the ambitious business analyst is going to put their head down and push forward as hard as they can and try to get a project going out of what they have so far. And continuous client promises of a decision by the end of next week, or an agreement after one more discovery call, leaves a deal too close to pass up after you’ve already put weeks or months into trying to finalize the deal.

Suddenly, you look back and six months have passed. If you truly reach that six-month milestone, it’s probably time for the business analyst and project manager just to give up. You can’t turn a potential project customer into something they are not.

You know the saying; “If you love something, let it go…if it was meant to be it will come back to you.”

Is there a way to avoid these types of situations?

Probably not. But it may be that we could ask better questions up front. We never want to sound too pushy, of course. But it’s fair to ask if there is budget approved for this project, if the project is backed by senior management, or if there are high-level requirements mapped out already.

Have they gathered end users and questioned them on the potential project? The bottom line is this; have they really thought this through in terms of need and finances before they came to you or did they come to you fishing for some ideas?

If you ask the right questions, you can find out if they’ve really thought this through, if it’s a project with money and thought behind it or if it’s just in it’s just a concept in its infancy. You may even find out if they have decided if you’re the fit if it does become a project. You might just be one of fifty that was selected to be pinged with an email or phone call to get some information that might help them along in their decision process.

Be careful, however. If you give them a lot of good information, you may become the single source of providing them with planning info that they have no intention of paying for in the long run. I’ve been there. I think I’m in one of those situations right now, but I haven’t quite figured out if that is the case or not…so I’m hanging on.

Can we more easily turn them into real projects?

The quick answer is that you won’t be able to, or that you’ll fail more often than you’ll succeed. You can’t force something that was never really meant to happen. However, if you feel you are close and that the chemistry is fairly good, then the thing that may push it over the line into real project territory is one of two things; 1) drop the proposed price or 2) the addition some interesting service or add-on product. Giving them back some of their proposed dollars or giving something of yourself or offering for free can turn some of those “explorations” that never end into a real project.

Summary / call for input

We think we are in control, but we aren’t. We are the experts and possibly the business analyst is the most expert resource of all on each project. Still, these situations happen and can be so extremely frustrating. Just when we think we are about to get a new project in place and ready to move forward, the customer may throw a new wrench into the process or need more time or need more funding. You can’t force a “yes.” You can maybe negotiate a “yes” by giving more away for free, but at the business analyst and depending on your organization, you may not be able to negotiate too much or make that call. Again, it can be incredibly frustrating. If you are in a position to do some negotiating, then consult with the project manager and team and weigh the options. But be sure to think about the long term, too, not just the short term. And then decide – keep going or give up? That’s about the only amount of control you can have.

How about our readers? Have you been in a position with a project client that seems to be in a holding pattern indefinitely? What did you do to push it toward being a real, viable project? Were you successful?

5 Signs You Need a Different Business Analyst on the Project

Written by Brad Egeland on August 10, 2016. Posted in Articles. 1 Comment on 5 Signs You Need a Different Business Analyst on the Project

A great business analyst can really make the technical project very successful.

I’ve had the pleasure of working with some very good business analysts along the way, and my project successes have been frequent as a result. Having very competent business analysts to work with has allowed me to focus more on my critical project management tasks and to be more successful and client-focused as a result.

That said, there can be times when the project seems to be suffering at the hands of a less-than-productive or competent business analyst. It hasn’t happened to me, but I can look back and see times where my projects would have suffered had any of these come to light…and I’ve seen colleagues’ projects suffer in some of these areas. Here are six signs that the project business analyst likely needs to be replaced – no matter where you are in the project timeline.

1. Can’t get requirements finalized.

Not all projects have the luxury of having a project manager and a business analyst; I realize that. But when they are separate positions, the business analyst is going to be the go-to tech liaison. If requirements aren’t well defined, as a task, responsibility and accountability for that is going to fall more on the shoulders of the business analyst. And if they aren’t working well with the project manager, project tech team and project customer to get those detailed requirements figured out and well documented, then that business analyst likely needs to be replaced before it’s too late.

2. Selection of the right technical solution is not happening.

The business analyst – after working with the project manager and project customer to define customer business processes in the “as-is” state of affairs and discussing what the “to-be” environment and processes need to look like – should be the lead on determining the technical solution. Along with help from the project manager, tech lead, and customer, the business analyst will likely be the one taking charge in determining the necessary technology to get the project to where it needs to be. If that isn’t happening, if the business analyst can’t make that happen, then they likely aren’t technically competent to work on this project. They need to be replaced at this early juncture before the project falls into a deeper technical state of trouble.

3. Tech team discord.

This is ultimately the project manager’s responsibility, but if there is a dedicated business analyst on the project, then he is likely the one working with and interacting with the tech team the most while the project manager focuses on the status and organizational aspects of the project. If the technical project team is not working well as a unit, then the business analyst needs to be aware and make or suggest adjustments, have team discussions, etc. If they work closely with the tech team, and that is the overall expectation and it isn’t happening, and there is discord among the team, then some of the tech team may need to be replaced. But, likely, the business analyst may need to go as well.

4. Tech document deliverables are not acceptable.

The project manager is ultimately responsible for every project deliverable that goes to the customer. I believe in having everything that goes out go through a peer review process. You can’t always guarantee 100% error-free deliverables, but if everyone on the team is reviewing everything that goes out, then that makes them accountable, too. With that many eyes making sure everything is in place, the chance that you’re sending out a bad deliverable is exponentially decreased.

I haven’t sent out a bad project deliverable in almost 9 years as a result of project team peer reviews on all deliverables. On a tech project, the business analyst is usually working extremely closely with the tech team to produce the project deliverable documents. If the functional design document or the technical design document or any similar documents are going to the customer with errors, then it may be time to replace the business analyst. You don’t get many second chances on customer satisfaction.

5. User acceptance testing goes poorly.

Often on a technical project, the tech lead will play a big role in user acceptance testing (UAT). I think we all know that on a technical project, user acceptance testing better go well, or there are going to be some big issues and problems with customer confidence, frustration, and satisfaction levels.

That critical UAT sign off is really the last significant approval point before the project goes live. If UAT doesn’t go well, then the project will likely experience delays, the budget will take a hit and – even if the project has been going well to this UAT point – it will still likely turn into a failure as it limps toward go-live after the poor UAT experience.

The business analyst plays a big role in holding the client’s hand through UAT preparation and the actual testing process. It needs to go well. If it doesn’t, you may need a new business analyst but it is likely going to be too late to replace them and find a new one. If any signs point to a less than well-prepared for UAT experience, then action may need to be taken BEFORE UAT. Not after.

Summary / call for input

Certainly overall responsibility for failure at any point in the project lies with the project manager. It is up to the PM to ensure that everyone fits well into the project team and to take action if that is not the case. But accountability for several key elements such as these on any technical project usually goes to the business analyst. These are critical elements to project success so if they are suffering, the business analyst may need to go. Be proactive, watch for signs. Take action.

Thoughts? Do you agree with these areas? What others would you include? Please share and discuss.