Author: Brad Egeland

Key Variables to Remember When Planning Projects

Written by Brad Egeland on February 8, 2018. Posted in Articles.

No surprises, no variables, nothing changes during the life of a project, right?

Sure. Raise your hands if you’ve ever managed a project that hasn’t experienced at least one change order / scope change. No hands? Didn’t think so. I know I haven’t had one and that isn’t a indication of poorly performed requirements definition efforts or poor scope management. It’s a case of long projects fleshing out slightly more complex or detailed requirements along the way and the delivery team ==> customer team relationship evolves and the delivery team’s (and customer team’s) understanding of the business processes and needs in play and the “as is” vs. the “to be” environment becomes clearer.

So what varies from project to project that can affect the project, the planning, the schedule, the budget, the requirements, the templates… maybe even the methodology and how you manage the project. After all, projects are never really cookie cutter projects, you need to look at each one uniquely anyway, right?

The customer.

Obviously, the physical customer varies from project to project – although you may end up running several projects over a period of time for the same, satisfied customer… and that’s aways a good thing. They only come back if they’re happy – and have budget for it. And with the varying customer comes varying needs, varying wants, varying neediness, varying wishes, varying awareness of their own business processes and requirements, and varying understanding of technology and the necessary solution. Some customers will participate as if they are part of the delivery team and some may disappear for most of the engagement because they either don’t have the time to be involved or don’t have the inclination to be part of the actual project work and progress.

The money.

Certainly the money varies with each project engagement. Every project has it’s own budget and, likewise, every client has an amount of money available that they are willing to spend on your services. My favorite client is the one who understands the value of the offering and isn’t trying to get the cheapest deal or project proposal possible. You can make yourself the cheapest option when you are trying to land a project and bring a client onboard, but that doesn’t make you the best and may actually weaken your ability to deliver on the project. Funding for the project may be so low that the project won’t be a high priority for the organization, making resources and time devoted to the project hard to come by and therefore your ability as the business analyst hard to deliver on. That’s a lose-lose.

Likewise, you don’t want to be trying to overcharge a client either – give them a reasonable and accurate price. Then wait.. and listen. Don’t negotiate to a lower price if it will mean you lose money unless landing this particular project customer is truly worth such a scenario. Be ready to say “yes”, “no”, or “let’s talk” depending on how bad you want this project and how flexible you can be. It’s always ok to say “no” and walk away.

The team.

Your project team is going to vary from project to project. In a matrix organization, you’re going to work with some team members over and over again, but the overall makeup of the team will likely never be exactly the same again – depending on how large your organization is. So, it’s a given that the talents, emotions, collaboration, cohesiveness, and accountability will vary somewhat from project to project and team to team. And just because you have 90% of the same team back from a very successful project for the next project… don’t assume that the new 10% will just fall in line and be just as successful and collaborative, and team oriented and cohesive. They may actually become combative and cause other team members to be less productive, efficient and cooperative as well. You’ve heard the phrase “One bad apple can spoil the whole bunch.” That can also be true of the project team. So the good business analyst needs to be able to recognize team chemistry and never take for granted or assume that team members that worked well together before will be able to replicate that – even if there are no new team members. Be ready to deal with conflict and confront team resource issues head on.

Key assumptions.

Documenting, clarifying and revising assumptions before the project, during kickoff and throughout the full engagement is critical to success. And assumptions are going to vary from project to project. In fact, as the experienced business analyst on the project, you are likely going to be in the best position to document key assumptions for most projects as you have both a technical understanding and a project management strategy and delivery understanding of the project as a whole. Assumptions on a technical project are not just technical in nature, but also involve vendors, risks, and even input and actions of the customer and supervisors. The project manager, customer team and tech team will also be key managers of assumptions throughout the engagement.

Outside vendors.

Outside vendors on any project can present a wildcard type of affect – and the vendors as well as their level of affect and impact on any given project will vary from project to project. The database supplier on a pharmacy or medical project – with all of the related HIPA issues and drug / prescription information is very different than the database supplier on tools and car parts information. The variance can be great from project to project and from industry to industry.

Risks.

Finally… those risks. Several risks are going to be a given on every project and should probably be hard-coded on to your project risk registry as you begin the risk identification and management process. But many of the detailed risks are going to depend on the vendors used, the technology used, the requirements of the project, the customer’s environment, and the project team… just to name a few. The business analyst and the project manager – actually all stakeholders – need to play a part in that risk identification process and the overall risk management process… it’s too important not to do it right and dedicate the proper time and effort and dollars to the management of those varying risks.

Summary / call for feedback

I realize this is just the tip of the iceberg in terms of what varies from project to project as no two projects are exactly the same. But I think this is a good start on some of the big ones and more obvious ones that will vary no matter what the project is or what the industry is.

Why Wait for Project Kickoff – Let’s Go!

Written by Brad Egeland on December 19, 2017. Posted in Articles.

Business Analysts… has this ever happened to you?

The project customer that you are getting to know pre-kickoff or the project manager or anyone on the team or even your own senior management wants to start a project right now? Today. No matter what. Let’s go. What are you waiting for?

It’s hard sometimes to wait and do things right. I realize that. But as the business analyst assigned to the project, you are tasked with helping the project manager make sure everything is in place, all those ducks are in a row, and everyone is on the same page before you start. I’ve seen it happen before – I’ve been in the middle of it on a project I was assigned and went onsite to the customer. Truly, finding out a little too late that you are starting a project that really shouldn’t be started yet can be a resource, timeline and budget nightmare. Not to mention it can cause setbacks with the project customer – even if it was their decision to move forward now in the first place – that are hard to get past. First impressions are everything and you end up looking like an idiot who is not in control of the engagement when a project starts prematurely and needs a restart. It isn’t pretty and it is never fun.

So, how can this be avoided? In my opinion, there are five things that you need to know – especially on technical projects which are mostly what I deal with – before you can really kick the project off. As you read through my list, please consider your own top 5 or things that you would add to this list and let’s discuss.

Has the customer had any necessary training?

Sometimes, in order to successfully nail down project requirements, the customer needs some knowledge about what your product is and does. If they don’t have that, then they may have trouble giving you a clear picture of their relevant business processes that are being affected by the solution. It’s hard to go from the “as is” to the “to be” if you don’t know what is getting you there. If a little training or a couple of webinars will help them get there and make requirements definition successful…and shorter…then halt the project and provide that training. You will not be sorry and neither will your client. I’ve had to do it…trust me it was worth it.

Is funding in place?

The money issue. Is it really available to make this happen? Companies fish around with consultants and project customers fish around with delivery organizations considering potential projects before money is really in place to move forward. Sometimes that funding can take another six months…sometimes it never happens. It’s a painful question to ask so be careful. But if you sense it may be an issue, you need to figure out some way to ask this question.

Do we have the staff ready to staff this project?

Resource-wise, are we even ready to execute on this project. Do we have staff available to take this on? One organization hired me as a consultant to setup some planning tools just so they could figure this out on an ongoing basis because they had a CEO selling projects worldwide faster than they could staff and have available equipment for project execution. Signing up clients was never a problem, but executing on them because they didn’t realize their resource pool was expended was the problem. You’d think that’s a good problem to have but it really isn’t. I was able to help them solve that before they lost too much credibility with clients and then they were able to set realistic expectations with new clients on when they could really be ramped up resource-wise to execute on their projects.

Is the project feasible?

Is this project even feasible? And if it is feasible, is it even really worth it. I mean, we know that we can put a man on the moon…sure…but do you really need that and want to spend that kind of money? Heading in to kickoff and planning on something that logically can’t be done is a waste of time and money. Look at the proposed project on paper and make sure that it is a real project worth at least thinking about vs. some pie in the sky idea scribbled on a napkin by an executive at a bar at 2am.

Do we have some high-level requirements?

We all know that we are going to need to define real requirements with the client. But coming in we need at least a 10,000-foot view of what the client thinks they need. If not, it’s going to take a lot of project team time and money just to figure out what they need. Having some high-level requirements at least gets us in the same book if not on the same page. Working from high-level requirements instead of nothing at all can actually save thousands of dollars and many days or even weeks on the project timeline. If they don’t exist, send the customer home for a week to figure these out and then come back to the table.

Summary / call for feedback

The bottom line is we need the proper planning, schedule and kickoff meeting in place before we start the work. Too many things can fall through the cracks and cause project problems even before we get started and if we don’t stay in control from the start the project can quickly veer off track.

Readers – what makes up your list? If you haven’t had an anxious customer or team to quell yet, at some point you probably will so be considering this. Have you had any nightmares you experienced on projects that were forced to start before they really should have started? If this has happened to you, what did you do to fix it? What would you do next time? Please share and let’s discuss – it can be a painful experience and you may or may not be powerless.

What Gender Makes the Best Business Analysts – Men or Women?

Written by Brad Egeland on December 14, 2017. Posted in Articles.

What does it really take to be good business analyst? What sort of super powers do the best business analysts have?

If you’re reading this you probably either are one, you know one, or your a project manager who thanks the powers that be every day that you have a good one on your team. Now, that favorite business analyst that you’ve worked with a couple of times on various projects… is it a man or a woman? If you’re the business analyst with all the skills, what gender are you? And if you were to stand in a group of good business analysts… what is the prevailing gender? Look to the left… then look to the right… you know the game.

Seriously though… this is not a serious question. No, we’re just having fun here… no gender biases. Just a curiosity to see what others are thinking. I have a poll on my Facebook consulting page pertaining to this – I would appreciate it if you stopped by with your vote. And while you’re there, please join in the same type of poll about project managers. Which gender makes the best project managers? Is there a difference? I’ve written a similar article on ProjectTimes.com about which gender makes the best project managers so please give that one a read as well.

What factors can affect who we deem the best? I’m assuming our thought processes may be swayed by these three factors…

The gender of the majority of business analysts we’ve worked with (perception thing)
How most of our successful projects were staffed at the BA role in relevance to gender
The relationships – good or bad – that we established with business analysts on projects

In general, the projects I’ve worked on have probably been more male-dominated from the project manager role through business analyst to tech team. More project manager colleagues have been woman than those in the business analyst role – for reasons I can’t really explain. That said, let’s move on to some of the key characteristics – at least from my point of view – of good business analysts and see if that provides any insight…

Skilled communicator. A great business analyst needs to be a great communicator. Everything on the project that the business analysts leads or participates in from extracting to documenting design specifications, to working with the project team during development of the solution, on to assisting the project client with user acceptance testing (UAT), to managing third party vendors to closing out the project during implementation / roll-out and everything else in between that I missed in this long winded sentence involves good communications skills if it’s going to be done right. Who has the edge here… men or women? It’s just me, but I probably vote women.

Detail oriented. There is little argument that the role of the business analyst requires a detail oriented person. 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 on that role is required throughout the engagement, to work closely with the customer sponsor and their team and the delivery project team to define and document requirements, and to help track and resolve issues throughout the engagement. Which gender is more detail oriented? Looking at my own skills and experiences with colleagues and – on a personal side – comparing myself to my wife… I vote women on this one.

Critical thinker. Why critical thinker? On technical projects – and that is the type of project I’ve led or worked on for many years – 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 over and over again until the real need is surfaced and understood. Because of those activities, critical thinking and evaluation skills have to be high on the list for good business analyst. Who’s better at this… men or women? I’ve known colleagues from each gender who were great at this and others who were passable. For me, this one is a toss.

Strong customer interface. The great business analyst plays a key role in customer communication and management. I’d say that on most of my projects the business analyst has interacted with the project customer as much or more than I have. This engagement needs to be aggressive at times, but always polite, thoughtful and not too invasive as we need to be aware that our project clients have other work engagements than just the important project that we are leading for them. Who does this better? The general perception is that women are usually less abrasive than men, I think, so I hand this one to the female gender.

Good facilitator. The business analyst is going to be required to facilitate many meetings and sessions during the project such as periodically leading the team meetings, formal project status meetings for the project manager and other meetings as needed. This role will also facilitate functional design sessions with the team and customer as well as technical design sessions with the tech team. Other planning meetings, requirements meetings and meeting with the customer on UAT activities will also be required. From a facilitation standpoint… which is founded in detail oriented skills and organizational skills… I think I would vote women on this one. Do you agree? Yes, it depends on the person and type of project as do all of these skills and roles that are required. It also depends on the industry and the customer… that’s why this is all really just an exercise in discussion and debating… no right or wrong answers.

Summary / call for input and feedback.

As with the role of project manager, at the end of the day it’s all about project success. No matter what the business analyst is working on – team management, leading project planning discussions and efforts, keeping the customer engaged… and happy, and moving the project along from deliverable to deliverable, task to task and milestone to milestone, it’s still all about getting things done well and in a timely manner to keep keep customer confidence high and keep the team and the project moving forward on schedule and on budget and in a timely fashion. Which gender does that better?

Readers – what are your thoughts and experiences with this? What gender have the most successful business analysts you’ve known and worked with been? Why do you think that is the case? Were they more equipped to meet these or other key characteristics or is it more related to the workforce in general or hiring practices within the organization? Please share your thoughts and discuss…and please join the poll!

Get it in Writing – a Business Analyst’s Guide to Tracking Tech Projects Through Sign offs

Written by Brad Egeland on November 22, 2017. Posted in Articles.

Projects are all about documenting things, right?

Schedules, resource planning, budgets, budget forecasting, status reports, project plans, kickoff meetings, requirements, design documents, communication structures, testing, etc. etc. etc. The list goes on and on and on. Before nearly everything was done electronically, the number of trees that died for the sake of large projects was probably astounding. Now we rarely do anything with real paper – I’m amazed when I feel the urge to print out a document to do some review and editing on – it feels wrong but also very right at the same time. Depends on the document and level of detail I’m reviewing it.

Now, with all this documenting of everything – albeit electronically – there needs to be some form of acceptance. When I conduct project meetings I follow up with notes from the meeting and send them out to everyone. I request review and acceptance or changes by noon the next day so that we can all be on the same page. There is nothing worse than conducting what you thought was a successful meeting of 10 people and finding out there were 8 different versions of understanding walking out the door at the end of an hour long meeting. Not everyone has A+ listening or attention skills.

So, consider this…. project closeout is critical, right? There are often some critical steps to follow – either officially or unofficially – when closing out a project. Through experience, I have my “unofficial” closeout check list and it includes – at a minimum – the following…

Review the financials. Start by reviewing the project financials. Is everything still on budget? And just as important, are invoices being paid by the project client?
Re-review UAT. Was customer testing successful? Were there any remaining issues or action items that needed to be handled…and were they successfully closed out? Help the customer out – but don’t do the work for them… that would be a conflict of interest. But you know how to create test cases and test scenarios and they may not… so oversee that process carefully to make the UAT go as smoothly as possible… and with few or no delays.
Check the schedule milestones. Conduct a detailed review of the project schedule with your team and then follow that up with a review with the project customer. Make sure everyone agrees that all deliverables were delivered and all milestones completed successfully.
Finalize all training. Most customer solutions require some level of training to be conducted for the customer’s end user community. The training tasks were likely tasks you had built into the project schedule from the beginning. Does the customer feel adequately trained and ready to use the end solution?
Document lessons learned. Lessons learned sessions are skipped by so many project managers when even just a one hour phone call could end up being of great benefit long term. Don’t pass over this opportunity to learn from the project you’re completing…it can be invaluable.

Make sure you have all the sign offs. This one is critical and very important as a CYA (cover your a**). But it is also the project manager and business analyst’s way of documenting acceptance of everything important on the project. And since the business analyst is the most hands on individual on the project, official client sign off of deliverables, milestones, etc. comes through him. These sign offs are a way of documenting – officially – that all these things above have been completed and that the customer agrees they were finished appropriately.

What sign offs are we talking about? On a technical project there can be many – the business analyst is working closely with the project tech team and the subject matter experts (SMEs), some key end users, and the project sponsor or leader on the customer side… basically all of the customer project team… on many aspects of the project throughout the engagement. So anything that can be completed, officially handed off to the customer and considered DONE is a candidate for an official sign off.

Some areas that come to mind:

Functional system design
Technical system design
Plans and key documents that get reviewed like a communication plan, etc.
Functional design documents (FDDs)
Technical design documents (TDDs)
Requirements documents
Traceability matrix (if you create one)
User acceptance testing (UAT)
Any and all change orders
Any turnover/support agreement
Final system/solution acceptance and handoff

Getting sign off on these – at a minimum – on a technical project is very critical to the closeout of the project and to help ensure that the customer agrees with and pays for all the hard work you and your project team have put into the engagement.

Summary / call for feedback

Sign offs – real official sign offs – are good to have no matter how the project has gone and no matter what your relationship with the client may be. Things can go from great to bad in the middle of the project or 30 days after deployment, it doesn’t matter and you can’t predict it. But if you have sign off on everything important than you always have recourse to say something is done, accepted, approved, etc. and should be paid for or at least can’t be considered a reason for them to come back to you for what the client may consider to be unfinished business. You may be surprised how quickly a client who suddenly doesn’t like the outcome can come back to you asking for a refund or asking for more work, etc. even though they were happy with the work at the time and likely paid in a very timely manner for it. What I’m saying is… always avoid the potential risks and get it in writing.

Readers – what is your take on this? Have you had a situation where a client came back to you for what they thought was more necessary work or unfinished work and you either did or didn’t have official sign off? Has official sign off helped you get old invoices paid or change orders paid for when you otherwise may not have received payment? Please share any experiences… good or bad… you may have had and let’s discuss.

Real Business Analysts Don’t Play Ping Pong at Work

Written by Brad Egeland on November 7, 2017. Posted in Articles.

I recently saw an Argentina-based ad about a non-millennial who was hired to work in a creative company with lots of ping pong and alternative work arrangements going on and he was having trouble fitting in – and oddly an adorable pug dog kept showing up in the ad and staring at him.

He even missed the alert for work from home day and showed up to an empty office building. He was frustrated to say the least.

While things like sharing the elevator with bicycle riders carrying tires and bikes in the office place is normal as is many part time to full time work from home scenarios, I can empathize on other aspects of the creative workplace. They can be conducive to work but it can be a huge distraction as well.

Water cooler discussion is so overrated it isn’t even funny. I’m so much more productive working from home as I am organized and efficient enough to make it work. It probably isn’t for everyone, but when you have that nice office at the typical workplace you find yourself losing productivity to your employees and friendly co-workers who like to come and discuss their weekend activities for a couple of hours everyday. I have 10 more hours every week of productivity just because I’m working from home… and that doesn’t even address the time saved not driving to an office somewhere.

So let’s move beyond the ping pong and the open environment and the work from anywhere discussion and get to the real point – what are productive and effective business analysts focusing on? On the tech projects I have been part of, the business analyst is usually more focused on these five key project responsibilities…

Defining business processes.

Before anything else can be done, the business analyst must understand the business processes of the client organization and why the project is needed. That may include the client organization getting a handle on their own business processes. Please note that this is before project requirements are really determined, even if the customer thinks they know what those project requirements are. Whatever they have in project requirements, set those aside because everyone must first understand the “as is” state of the business processes and gain understanding of the “to be” plans for those affected business processes. This is the beginning of the high level project requirements. Or at least the beginning of the building stage of those project requirements.

Documenting project requirements.

The business analyst is involved in just about everything about the project post-kickoff and maybe even pre-kickoff if they are fortunate enough to get assigned that early (and if the project manager is fortunate enough to get their help, insight, and skill set that early) in the engagement. It is possible that none of this involvement is more important than the act of planning, extracting, sorting through, defining and documenting the complex and detailed project requirements for the project engagement. I’ve always said that good, complete project requirements are the lifeblood of the project. Without good, complete, detailed project requirements, you’ll likely miss the mark on developing what the customer and their end users really want and need. You’ll experience many change orders, re-work, missed deadlines, off the mark project deliverables and… in the end… have a troubled and frustrated project client who isn’t likely successfully using the solution as planned and isn’t likely to immediately run around giving you and your organization high praise and reference-able recommendations.

Moving user acceptance testing (UAT) along productively and successfully.

Another important area of coverage for the business analyst is the laborious, but critical process of user acceptance testing. The UAT is where the customer runs the basically finished technical solution through it’s paces and confirms that it does what they need it to do. What are they testing against? You guessed it… the project requirements. So going back to those… you can see at least one key reason those well documented project requirements are necessary. Another key input into the user acceptance testing process is the test cases and testing scenarios. Most clients aren’t very experienced in putting those together and actually performing the testing. The BA can’t really do all of this for them… that would be a conflict of interest because in order to get non-tainted sign off of the user acceptance testing it needs to be the customer performing all of these activities. But the business analyst certainly can and often does help – significantly help – guide the project client through this process successfully. The UAT does have a defined place and time on the project schedule – often one to two weeks – so it needs to end (successfully!) and then move on. The BA helps keep it on track toward successful sign off.

Ensuring the project is closed out successfully.

At the end of the road is the project closeout and final sign off and acceptance. The business analyst is always going to play a key role in this – working right along side the project manager to ensure all the i’s are dotted and the t’s are crossed. Have all invoices been delivered – and paid? Is the issues list signed off and complete? Have you checked the detailed project schedule again – are all deliverables signed off and accounted for? Have you touched base with the customer – are there any unknown outstanding issues or concerns that should be discussed prior to solution handoff? Are there any final outstanding questions or concerns from the subject matter experts (SMEs) and end user experts on the customer side? Those are the ones you need to make sure are ready for solution handoff.

Summary / call for feedback

This list is really just the tip of the iceberg of what the business analyst really does on the typical technical project and implementation. Did I say typical? I’m not sure if there really is such a thing as a typical technical project – it’s never that easy or containable. But the BA role is so incredibly significant and broad that what they end up touching is literally everything. This list just covers a few very key areas of involvement. And as far as ping pong goes… play away. I love ping pong and I’m very good at it… just not sure I want to hear it all day or have others playing it in the workplace, but I’ll get over it as long as I can find a good place to work that has a solid core door on it.

Readers – what do you think about this list? Do you agree with it – what would you add to it or change about it? What is your corporate culture like? Very casual? Too casual? Just right? Please share your thoughts and discuss.