Tag: Planning

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!

Why should Start Ups and SMEs start utilising the power of Analytics?

Written by Ben Fisher on December 7, 2017. Posted in Articles.

The impact data analysis actually has on enterprises of all sizes has been well documented in recent years to show the benefits an organisation will receive;

the ability to better evidence their decision making, pinpoint areas to cut costs, and drive profits. Large international corporations have been taking advantage of the benefits business analytics provides for so long. However, this is a completely different story when it comes to Start Ups and SMEs. Figures from a recent poll found that 56% of SMEs rarely or infrequently check their business’s data, while 3% have never looked at it at all.

Data Analysis is a big advantage for Start Ups and SMEs as it actively promotes growth which is the prime objective for most. Business Analytics when used correctly will help uncover hidden opportunities, identify trends, patterns and problem areas. In the UK last year, there was over 650,000 new Start Ups which shows how vital it is for those companies to take risks in their quest for growth. Analysing the numbers can help to reduce against these risks, and ensure they will provide some ROI and not bring down the company.

All foundations for a Start Up’s success are built around their idea or product. Unfortunately figures show that up to 50% of Start Up’s cease trading after 5 years. Accepting these figures is never easy if you’re a founder of a Start Up, but your chances of survival can be increased if you’re willing to accept these numbers and take time in understanding the market, products, customers, and data analytics. Taking advantage of free tools such as Google Analytics is vital in the early stages as this will allow a company to look at engagement metrics and feedback from users.

The main reason behind Start Ups and SMEs not taking advantage of data analytics tools is commonly down to the cost. Another common reason is simply down to the fact that they are occupied by other tasks. It’s obviously not going to be feasible for any smaller business to bring in a whole data analysis team in like larger companies are able to do, but appreciating the value that data provides, and allocating time accordingly can you give you insightful information . Analytics can help benefit Start Ups and SMEs in 3 ways.

1. The Initial Stage:

At the beginning of your business journey you are still in the discovery mode. The analytics strategy you have in place should allow you to make sure that you are tracking your current activities against your goals. So, if you were testing whether customers will use services provided through your website, you should be tracking the following metrics: Visits, Unique number of visitors, engagement of visitors and final conversion.

2. The Growth Stage:

This is the period when analytics can now become a lot of fun and be the true driver of your strategy. Agility is the key here. Think, test, implement and analyse your ideas quickly to see what works and what does not. It’s a great way to test out your hypothesis before rolling it out, try out variations in processes/customer journeys; you will only be limited by your own intent and imagination at this stage.

3. The Matured Stage:

You should now be in a position where you are using analytics to prescribe actions rather than to justify them. You will use your analytical capabilities to create a competitive advantage over others who can’t extract knowledge from their data, or act as quickly upon it. Make sure you don’t get left behind as the power and benefits of using analytics is growing more and more each year.

It’s Beginning to Look a Lot Like Collaboration!

Written by Tom McIntire on December 5, 2017. Posted in Articles. 1 Comment on It’s Beginning to Look a Lot Like Collaboration!

Collaboration is one of the most difficult actions we complete in the Business Analysis world.

Working with stakeholders can sometimes feel like a grueling task after weeks of meetings leading up to requirement approvals from stakeholders. I have discussed this topic in previous article I’ve written, but today I’d like to discuss collaboration among other Business Analysts when working on a project that involves multiple authors or writers of the same set of requirements.

In my experience as a business analyst the majority of the work I have completed involves a single business analyst assigned to a project, however, there are some projects that I have worked on that are just too large for a single business analyst to be involved and there are often 2-3 other business analysts working together to meet the project goals. This process can just as complicated as working with other stakeholders on a project. Opinions are many and voiced often. Temperatures run high at times. In the end, strong collaboration surpasses these complications and the end goal is achieved.

Below are some methods or techniques that I have followed over the years to help guide this process:

Plan, Do, Review, and Improve

The four phases of this technique – used to coordinate and publish complete and consistent requirements – are detailed below.

	Phase	Description
1	Plan	The architect or group of authors plan the work to be done once the high-level requirements (HLRs) have been defined. Planning includes the following: Determining and agreeing upon the HLRs for the project. Assigning HLRs or sections to the various requirement authors. Determining the structure in which to write the requirements. Determining a timetable to complete the various sections of the requirements.
2	Do	The authors create all functional requirements that lie within the HLRs or sections assigned to them.
3	Review	The requirement authors review each other’s work. They read through the requirements as if the subject matter were new, asking open-ended questions such as “How does this functional requirement connect to the scope?” and “Why is this requirement important to the scope of the project?”
4	Improve	Consider and implement the suggestions and comments received from the other requirement authors. Requirements should be improved through editing content, grammar, and requirement structure. Note: The Architect will be accountable for ensuring updates are made accordingly.

Requirements Workshops

Requirement Workshops can be very effective for gathering requirements. They are more structured than brainstorming sessions, and participants collaborate to document requirements. A workshop is an effective technique when there is more than one analyst working on gathering and documenting requirements through facilitation and documentation.

Through these sessions both business unit and development subject matter experts (SMEs) collaborate to define and review the business requirements for a system. This allows the two parties to resolve any differences of opinion regarding the design.

More information on Requirement Workshops may be found within the IIBA BABOK V3.0 Guide.

Architect

The architect of a project is responsible for the Requirements Architecture as a whole. He or she will own the role of owner of the requirements.
Responsibilities include:

Determine completeness of the requirements.
Determine consistency of the requirements.
Determine the requirements align with the scope of the project.
Determine the structure of the requirements adhere to the guidelines that your company has set for requirements writing and documenting.
Coordinate with the other requirements authors.

Additional Techniques

Additional techniques for collaborative writing can be found in a number of ways:

Printed and online publications specializing in Business Analysis.
Online academic or scholarly articles from leading business universities.
Industry leading conferences such as ones through the IIBA.
Industry leading webinars from sources such as the IIBA and Bob the BA.

A Project Full of Business Analysts

Written by Janet Walker on November 21, 2017. Posted in Articles. 2 Comments on A Project Full of Business Analysts

If you are your company’s only Business Analyst, you might have it easier than the rest of us.

You make the BA rules and you are always on the same page with yourself. You read all the articles on how to gather requirements and you have the documentation down pat. From beginning to end, you have all the answers, you understand the business need perfectly and you know things will go as planned. In your “the only BA” world, there are no surprises for you unless you forgot something or you assumed something or the change failed. My point is, you have the control and the full responsibility.

When BAs share a change or a project, things can get tricky … fast:

Get the BIG picture: If all of the BAs who will be involved in the project do not know the why, what and when, problems are a sure thing. For this reason, we want to avoid coming in late to a project or miss a kick-off meeting at all costs. We may not be good at having the right people in the room, so BAs need to be aware of initiatives coming down the road and make sure we are included day one. Every BA involved needs to start on the same page and begin communicating with each other right away. “Here are my take-aways” and “My change starts when you are done, but before ….” etc. I know, the big picture changes, but multiple BAs need to know where they fit in relation to different requirements. Chase that moving target down!
It’s all about Bandwidth: We are assigned to the same project, but I am ready to go and you are still finishing a different project. This means we have to talk about our bandwidth and our calendars – business and personal. We can agree on a date to start, but if you are OOO two weeks later for four days, I need to know this. My testing may need to be put on hold, I may start another task early while waiting for you to return. Share calendars!

The Multiple requirements: Our individual requirements may be different in why we need to make a change or build a new process, but we know for a fact that we are linked together by a common project. BAs that try to run alone during a multiple BA project end up taking everyone down because the loner was positive their changes did not impact anyone else. We need to look for those points where our process starts, updates, communicates and hands off to the next step in the big picture process. Meet with the BA that is making changes that flow into yours or just before your changes. Document this info. If you are updating, find the BA who supports what you are updating/adding/cancelling/communicating and make sure the format is expected and the timing is correct. Document this info. Understand what happens when your personal process change ends. Find the BA who takes it from there and make sure they have what they need from you. Document it.
We got test plans! : My test plan tells me I have my ducks in a row, just the way I planned. What it doesn’t tell me is how my changes fit in with anyone else’s changes or an existing process. Reach out to the other BAs on the project and ask them to let you know when they are ready to test with you. Don’t be surprised when that BA who is used to working in a silo pushes back. This is our opportunity to make all the BAs better by saying we want our project to run smoothly. 😉
Uh-oh: Such a great feeling when the changes move to production and things are working as expected! Yes, but when something goes wrong it is also a great feeling having BAs working together to solve the problem. Nothing is your fault. You worked together and communicated about the why, what and when. You all built the new process together and a hiccup anywhere along the line means everyone has the hiccups. You can hear the conversation now – “We tested this piece, right?”, “What did we miss here?” and (my favorite) “Umm, I never heard that was a must have, did you?”
A team failure is quickly another team win when the group solution is found and the lessons learned are discussed after the fix is in. This kind of win is huge!

So, get on the same page, communicate regularly, support each other and provide a second set of eyes. Know your peers that are involved and what kind of knowledge they can share with you and let them know you are available to return the favor! BAs working together on requirements and changes make for a strong project.