Skip to main content

Author: Brad Egeland

Top 5 Toughest Questions Faced by Business Analysts on Tech Projects

Written by Brad Egeland on . Posted in Articles. 1 Comment on Top 5 Toughest Questions Faced by Business Analysts on Tech Projects

We all have to face tough questions – difficult requests from time to time on the projects we are working on.

From our team members, from our leadership, from our customers. It happens. What are the toughest questions you’ve run into on the projects you’ve worked on? Be thinking about that as you read these words. I guess some of these aren’t such difficult questions, but they can be very common and can be the result of mis-information that was not within your control… leaving you to clean up the situation or get all parties on the same page and moving forward toward the same goals.

So here are my five biggest, toughest and probably most common complex questions that come up on the projects I’ve led or worked on – specifically technical projects. Please be thinking about your own personal five and share your thoughts at the end. Thanks!

Why isn’t training included?

Don’t get me started. Ok, I will start. This has happened to me more than once and it has always been a due to a disconnect between what the customer needed to help us understand what they really needed and what the sales team told them and sold them. If your client is buying a customizable solution then they need some understanding of how that custom solution should and will work to meet their needs and business processes once it’s configured for their end users. They need to be able to help you document requirements and test the solution.

Can you make this technology work?

I’m guessing this is fairly common question. Many clients come with an idea of the technical solution and sometimes they are looking for the latest and greatest bleeding edge technology and they want to showcase it on their project in their business unit. Can you make this work? No pressure, huh? The project manager and the business analyst must stick to their guns and come up with the right shaped peg for the hole… not trying to shove a square peg in a round hole just because the client is requesting it. Why? Because at the end of the day, if it doesn’t work… it will still be your fault no matter who demanded it.

Advertisement

Can we move these phases around in the schedule?

This will eventually fall to the project manager because it’s a project schedule issue to resolve or negotiate. But that initial request and the need to figure out if it is even possible will at least initially fall to the business analyst to liaison with the project manager and tech lead to discuss and figure out if it’s feasible. While this may come up from time to time, it is far from typical or easy to answer. Much has to be analyzed. The affects can be small – but often time they are far reaching and with a change like this can come risks. How will the remaining phases be affected? How will testing and acceptance be affected? How will the budget and and project timeline be affected? All potential risks, problem areas and touch points must be identified, discussed and addressed.

I need this but I have no budget. How much will that cost?

Changes come up on every project. The problem is the customer may not have budget for all those needed aspects and functionality of the solution that didn’t quite come up at requirements definition time. Now those are change requests and they want the change for free. The customer asking for something for free? That never happens. Right. But you can’t blame them for trying. Business analysts… if you haven’t been asked a question like this on a technical implementation then you must be living under a rock.

Can you replace one of the developers on the team?

From time to time you may run into a client who doesn’t mesh well with someone on the team. You may get subjected to a specific request to replace a particular member of the team or receive some negative feedback about one of your co-workers. When of my project customers once asked me to replace the tech lead because he was always showing some much frustration and concern over every issue that came up on the project. It made the customer feel uneasy – like he had very little patience and ability to deal with difficult situations. They wanted him replaced. I talked it over with the tech lead, explained the situation and asked him to not make it sound like the sky was falling every time there was an issue – but rather to show confidence. It turned things around and they did stick it out with him… eventually very much enjoying working with him by the end of the project.

Summary / call for input and feedback

At the end of the day all we really want to do is implement a great working solution for our customer and their end users. Then we want to ride off into the sunset and basque in the glory of a successful project well done on the shores of Belize for a couple of weeks sipping on margaritas. Is that too much to ask? Well, yes, it is. In reality we are sometimes happy if we can get out of town by the dark of midnight with a customer who had a good solution in their hands and can now contact tech support for help rather than ask the delivery project team every question that comes to mind. At roll out customers can sometime be as nervous as a kindergartener getting dropped off day one of school and doing everything they can to keep mom or dad from driving off in the mini van and hopping a plane to Belize.

Readers – especially business analysts – how do you feel about this list? Do get asked about free training, specific complex technology as a solution, free changes, or new team members to replace existing ones that the customer just doesn’t like? Please share some difficult questions and requests that you’ve had to deal with. How did you respond? Please share and discuss.

The First 4 Things the Business Analyst Should Know on a New Project

Written by Brad Egeland on . Posted in Articles.

Know may not be the right word here…it may be more like ask. If there’s anything I’ve learned about projects in the past 25 years, it is this…if you need information, don’t wait for anyone to give it to you.

Ask for it. Demand it. Dig your heals and and don’t move until you have it. Hold a meeting to get it. Extend the kickoff meeting an extra day in order to get it, if necessary. But always try to get as much information about and for the project up front in order to help you down the path to a successful project conclusion. This is true for the project manager and it is also very true for the project business analyst.

So, let’s consider the first four things the business analyst should ask about or ask for or know when they are about to begin a new project. The project manager is the project leader and hopefully knows this information or at least has a good idea of it.

What the delivery project team looks like – skill set, etc.

The business analyst is the go-to liaison between the project manager and the technical team. Knowing what he has to work with on the technical side is critical information as he prepares for project kickoff and the next phase design work on the project. In fact, the business analyst, once he has a handle on the project and the requirements at least at a high level, then he should have some input into the make up of the project team. Usually the project resources are requested by the project manager based on the skill set needed and the roles that will need to be filled in order to complete the project effort. The business analyst would be a good – make that great – source to go to in order to make those project resource requests the best and most accurate they could possibly be. The business analyst knows the technical side and should be providing major input to the creation of the project team resources.

The customer team make up.

Likewise, knowing what the customer team make up looks like is critical for the business analyst as well. Why? Because the business analyst will be constantly interacting with the customer on various issues including clarification of requirements, work on change orders, questions about current and future business processes that affect or are to be affected by the project solution, user acceptance testing and what the end user community is expecting to see. If the business analyst has an idea of what they are working with early on in terms of the customer team formula, it will greatly help their planning and will likely have an affect to some degree on what resources are going to be needed on the delivery project team side as well.

Advertisement

What experience and infrastructure the customer has for the likely solution technology.

Are you using cutting edge technology on this new customer project or is it something both the delivery team and the project client are already familiar with? I realize that this is something you may not know completely until the final requirements are fully documented and the project is underway. But often the technology or process that will be used on the solution is known already or at least both sides have a very good idea. This information is helpful to the business analyst on the project for resource planning purposes, for requirements documentation purposes, for helping the client define their own project team and for helping the client define the “to be” business processes that the project solution will be implemented to. It is also very helpful to know this as any post-project technical support and training is being planned for and – again – these are things that the business analyst would be heavily involved in. The training may even be something they design and lead for the project customer.

The state of any high level requirements or business processes.

Finally, what is the state of the project requirements and business process definitions coming into the engagement. There are those clients who have done the work and know what they want, know what they need and have a detailed list of requirements a mile long. That can be a very good thing. It can also be a very bad thing. This type of client may “want” this, but unaware that they really “need” that. And it can be hard to convince them otherwise. Or, in the perfect world, maybe they have all those requirements and project needs documented correctly. Not likely…but maybe. Often times the project client has some idea of the need but it may only be a symptom or 80% of the real need. It’s up to the project team to figure out the real project and that investigation is really the responsibility of the business analyst. It may be led by the project manager and it may be acted upon by the entire team – tech lead and all – but at the end of the day it is the business analyst really leading this effort as they are working on complex, detailed, final documented requirements.

Summary / call for input

I’m not saying that knowing all this information at the outset will end in a successful project implementation. And I’m not saying this is all he needs to know either. But these are four key elements of input from the beginning that will help get the project started off on the right foot and help the business analyst to move forward more confident of a successful project outcome in the end.

Readers – what are your thoughts? Business analysts…do you agree with this list based on your project experiences. What are some other things you consider important to know up front as you move on to a new project? Please share your own experiences and thoughts and discuss.

Why Business Analysts Become More Necessary in 2018

Written by Brad Egeland on . Posted in Articles.

I certainly understand that the luxury of having a project manager and a business analyst on every project isn’t something that every organization and customer can realize.

However, with ever growing annual concerns over data integrity, hacking, cyber crime, information security and the increased financial threat of ransomware it may not be a luxury going forward. In my view, gone are the days when an organization should take the risks with having both key roles handled by one individual or even including the tech lead role combined into that one super human entity. Gone. That was 2000 or perhaps even 2010. But the climate has changed drastically and it is a more dangerous and less forgiving tech world out there now as we approach 2018 and beyond.

When I quizzed just my circle of current and past clients a little over 40% of them responded that they had been the victims of at least some sort of hacking incident in the past year. Thankfully none were a result of any oversight on my part and thankfully none were serious or of the ransomware variety. But still… more than 40%. Wow. I was guessing the number would be closer to 10%. Surprise, surprise. But this is reality and we have to get used to it – and defending against it and trying to avoid it will take time and money and still there will never be any guarantees. Do we want to cut corners on our critical projects? Do we want to reduce budgets and personnel needed to hopefully keep our data safe and our clients happy? Probably not.

For the purpose of this discussion, I’d like to cover some key reasons why business analysts become more of a necessity than a luxury in 2018 and beyond… and now, actually. Let’s consider these reasons why business analysts are a must on projects in 2018… in my opinion… and please share your opinions when you’ve finished reading this…

Cyber security needs increase.

Everything can be hacked and the use of ransomware is growing fast. So concerns with sensitive data on our projects has now grown from just sensitive client data falling into the wrong hands to the potential to have to pay millions of dollars to someone who can grab the data but doesn’t want it for anything other than financial gain from you.

Having the business analyst inserted on every technical project as another layer of skilled oversight plus the combination of business process and technical understanding that the good business analyst brings to the table will help alleviate some of the risks. Our data sensitive projects must have a business analyst working alongside the project manager, technical team and customer now and in 2018 and beyond.

Advertisement

Cross over skills necessary as more budgets tighten.

As project and organizations’ budgets tighten, having the business analyst role becomes only more critical. The business analyst can help fill the void left by an understaffed technical team – not as a coder but certainly in a design and process configuration mode. And the business analyst will help when budgets are tight by further ensuring the smaller likelihood of rework and poor requirements definition due to their dual responsibilities, understanding and skill set.

Data integrity at the center of most tech projects.

At the heart of many – if not most or all for that matter – IT projects is at least some sensitive data. If it isn’t data being processed by you or by the project client that is involved in the engagement you are managing or the technology you are implementing for them – like a new accounting system for example – then at least your handling of the client information is sensitive. And any or all of that data’s safety is at risk on every project you manage or work on. Along with that is client confidence and satisfaction which will also be at risk on every engagement. That risk is increasing daily with each new report of a data breach by skilled hackers. Having the experienced business analyst role filled on the project is essential to detailed understanding of the client’s business processes and any potential vulnerabilities or security risks that may be present.

Project teams are stretched across multiple projects.

The business analyst serves as that technical liaison between the project manager and the technical parts of the project team and with the project customer in many areas. The business analyst is also most likely thin across multiple projects, but the role is still essential and critical to help ensure gaps are filled and business processes on the client side are properly understood, documented, and translated into the requirements, the functional design and the technical design. That is the groundwork to building a good system that will minimize potential risks.

The gap between project manager responsibilities and tech team liaison needs is widening, not shrinking.

The project manager has enough on his plate. The tech team and tech lead are deeply entrenched on the detailed technical solutions that our tech project clients are demanding and in need of. They are getting more complex as technology solutions and implementations become more complex. The need for the business analyst liaison role to bridge that gap is becoming greater – not smaller. And it will probably never get smaller – only those in denial will try to skip over that gap thinking they can save money in the process only to find they quickly lose it in rework and scope management issues. It’s only going to get harder and harder and technology is only going to get more complex on these projects we manage.

Summary / call for input and feedback

In my opinion – and from my experience – the best route is to always have a project manager and business analyst in designated and dedicated roles on every project. I realize there are organizations out there and projects to manage and customer wants, needs and budgets to worry about where that may not be feasible financially or on the table as per the timeline. But it works, and it works for the best.

Readers – what is your take on this? If you’re a business analyst, do you think your role is or will become necessary on every project? If you are a project manager, do you have a business analyst assigned to every project? What is the business analyst model in your organization? Please share and discuss.

5 Reasons Why the Business Analyst Needs to be a Cyber Security Expert

Written by Brad Egeland on . Posted in Articles. 2 Comments on 5 Reasons Why the Business Analyst Needs to be a Cyber Security Expert

Ok, maybe not “expert.” But on the projects I manage – which are almost always technical in nature

– the business analyst serves as that technical liaison between the project management world and the technical analyst or the technical lead world. The Business Analyst takes business needs and translates them into functional design requirements so everyone can understand the needed functionality. The Business Analyst then assists the technical lead and technical project team members in translating functional requirements into technical design requirements to allow the technical team to take off and create something usable and real.

For this reason, I say the Business Analyst needs to be a well-versed technical resource. Systems are hacked constantly making security risks critical. The Business Analyst needs some expertise in cyber security to address the potential project security risks. Here is a list of five reasons why the business analyst needs to have some cyber security expertise.

1. Everything Can Be Hacked

Literally. Anything. Can be hacked. You can deny it, but attend a Black Hat conference or just look around. You’ll realize we are only fighting to keep up with – or lucky enough to stay one step ahead of hackers. While we are planning for risk, performing design and development on our solution, hackers have nothing else to do than work on hacking the latest technology. And there is more than one of them. Do I sound paranoid? I should…because it is true. We are on a collision course and eventually will lose. So on our projects, we need consideration for cyber security, cyber crime, and information security. The Business Analyst is the natural go-to person on the project team to be the most informed on these topics. Address cyber security on each project you work on from this day forward, you won’t be sorry that you did.

Advertisement

2. Data Sensitivity is Broader Than You Think

Your data on your project is more desirable and more sensitive than you think. Sure, there may be those projects that no one will care about, and no one would ever want or need to hack. If you are handling financial data of any kind or even consider the financial information of your project customer that accounting is handling (as well as any vendors you are using), it all may be desirable, and it all eventually will be hacked. The business analyst is that PM ==> Tech go-between resource and must stay technically current on the security niche.

3. Cyber Security is Part of Risk Management

Risk management needs to happen on every single project. Although in reality, it doesn’t happen on every project. When execution of risk management does occur, it is not happening with a level of detail that is insufficient. This is based on surveys I have conducted, surveys I have read, and my experiences. And, if risk management should be happening, then cyber security concerns should be coming to light during that risk management planning because it has to be part of the risk management process. All of our projects are in some medium to urgent need for cybersecurity measures, and we need to react accordingly. Until cyber crime vanishes then it has to be part of risk planning.

4. The Business Analyst Has Something to do With Everything Technical

The Business Analyst is the technical liaison between the Project Manager (who should be at least somewhat technical), and the technical lead (who should not in any way be a project manager-type) means the Business Analyst is walking a fine line. The Business Analyst is not overly technical but has enough technical knowledge to understand where in the requirements, functional design or technical design need security considerations. The Business Analyst focuses on matters of data security and integrity throughout the project, not just during design.

5. The Business Analyst is the Go-To Solution Resource.

The Business Analyst is – or should be – the go-to technical solution person on the project. The Business Analyst is not expected to be the most technical, but certainly when working on technical projects to have some technical expertise. By default, that means he or she must be up to speed on cyber crime issues, concepts, resolutions and mitigation procedures. Are Business Analysts cyber security experts? Maybe not an expert, but they should be close with cyber and data security experts inside and outside of their organization.

Summary and Call for Input

My title for this article may be a bit strong. I conclude that the Business Analyst is not necessarily a cyber security expert. Business Analysts who may not have much cyber security knowledge should consider obtaining a high-level understanding of cyber security. If you are a Business Analyst working on technical projects such knowledge is of great benefit to the project and organization.

What are your thoughts? Are you a Business Analyst that feels cyber security is a good fit to drive cyber security awareness? Please share your thoughts and experiences with cyber security on the projects.

5 Steps to Improved Project Team Collaboration

Written by Brad Egeland on . Posted in Articles.

Team collaboration and communication is critical to project success.

The project manager organizes the project and provides scheduling, budgeting, resource planning and usage, communication and customer engagement oversight throughout the project. However, the business analyst is often the one in the trenches with the project team on a daily basis – often interacting on the individual tasks the team is performing both with the team and with the project customer. You can see how team collaboration would quickly be at the forefront of project success especially on today’s projects that often being carried out by virtual teams that may never come face to face with each other.

Let’s consider five possible steps to be taken to improve the project team collaboration on a day to day basis:

1. Know the Team

In this age of virtual teams, individuals may go through entire projects without ever meeting their team members – or even the client – face to face. I have carried out projects lasting 12 months or longer without meeting any of my team in person or even the customer. The key is communication. To create a close knit team, you must connect with them on a personal level as well. I always suggest at least a weekly team call. Unless something urgent must be discussed immediately, initiate the call with some lighter conversation. Start going around the group and talking about what activities they have going on outside of work over the weekend or next week. It is an excellent way to build some cohesion beyond just the task commitments. Everyone hates having their picture taken, but having a photo on your email signature line or profile in the system gives a face to the person on the other end of the phone call. We humans can feel empathy and comradery when seeing a person’s face because it is how our brains our wired. When we see a person’s picture, we feel closer to them personally.

2. Get Input from Everyone

Always include the entire team on important meetings, decisions, and communications. If you get in the habit of going only to a tech lead or data specialist for example on a given project before you know it that is all you will have left. The portion of the team that is always being left out will start to shift their focus to the projects where they feel they are making bigger contributions. You do not want that! Include everyone, even if you still have a go-to guy on the team for most of what you need. The team that keeps excellent communication where everyone is providing input is the more productive and accountable team. That is what you want for your team.

3. Allow Everyone to Face the Customer

Make sure everyone is interacting with the project client. It increases the feeling of contribution and accountability for the project team members. With that increased feeling of contribution and responsibility you will also likely see an increase in participation, cooperation, and performance. People want to be wanted. I want you to want me, remember? What is the easiest and best way to do this? Some of the team will frequently be interacting with the customer already – especially on a technical project where early on some requirements and business processes may need vetting. However, another great way – a way I have always used – is to allow (or force) each project team member to report on the progress of their key project tasks during the regular weekly status calls with the customer. This increases accountability and ownership of tasks and increases collaboration as they work to ensure that they have made as much progress as possible and that everyone on the team is up to date on their task statuses before these calls.

4. Use a Collaboration Tool

Believe it or not, on individual projects the tool can make a big difference. Moreover, if it is a collaboration you are in need of, then that has to be a significant project management consideration. Alternatively, you can set up a “home grown” collaboration method. However, there are enough project management related tools out there to research and try out where you can fully collaborate through the given tool of choice and not have to resort to a closed Facebook group. Can you tell that I have done that on a project or two? There are better choices out there to review. It takes time, but contact vendors, demo alternatives and find the one that works for your teams and organization and maybe your customers depending on whether or not you want them involved in the collaboration process. At a minimum, you want to be able to communicate and share documents and revisions through the collaborative tool. Proceed carefully. Complex collaboration tools that are difficult to interact with may break down communication for the team.

5. Clear Team Member Availability

Finally, to ensure you have full team member participation, collaboration and cooperation on high priority complex projects, make sure your team members are indeed available for the project. I’ve had several projects start well only to find that a given team member was stretched too thin or involved in another, possibly higher priority project. When issues arise on one of those other critical projects you may lose that essential resource either temporarily or even permanently. That can be painful and onboarding new resources is not without extra costs and sometimes lost in the process – not to mention causing almost immediate concern for the client that their project may not be very important to your organization if they are losing resources to other projects and other clients.

Summary

A tight team is a dedicated, ready to follow you into a battle. Excellent communication and collaboration is the key to most of the project success you are going to experience on any given engagement. Without good communication, requirements will get missed or miscommunicated, deadlines will come and go without successful delivery, and re-work will undoubtedly happen. All of these will serve to inch your project closer to overall customer dissatisfaction and project failure. You do not want that, so get started on the right foot from the outset. These are five of my proven steps to build the best team collaboration and avoid the pending glitches. I probably have more…

Readers: What are your steps? What do you do to build a close knit team and ensure the best and most efficient collaboration and communication possible? What problems have you encountered? What successes have you experienced? Please share and discuss.