Tag: Best Practices

How to Handle Tight Deadlines as a Business Analyst

Written by Sergey Korban on November 30, 2010. Posted in Articles.

When you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking – I know this from experience. It’s like driving a racing car – you have to push close to the limits but any error can throw you completely off the track.

The first thing that I do when I get a project like that is considering the reasons for the deadline. You can end up with a tight deadline for a variety of reasons. The deadline may be mandated by the management. It can be determined by interdependencies between projects. It can be defined by market compliance rules. In other cases it’s estimated using the work breakdown structure for the project but ends up being too short because of wrong assumptions.

So how can you as a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully? Keep in mind that sometimes you can be successful even if you don’t meet the original deadline!

Here is a visual summary of deadline causes and ways of handling them:

Let’s look into the ways of handling deadlines in more detail.

Manage the Manager

Management sometimes sets up deadlines with a good “buffer” to allow themselves time for decision making at the end of the project, or because they don’t expect to get results on time and want to push things along by moving the deadline forward. This can be best mitigated by having good communication with the management.

However, what can you do if your manager does set an unreasonably short deadline? Find the tolerance level of your project sponsor (management) and of the key stakeholders who can influence the sponsor. Talk to end users to understand the severity of not delivering on time. There can be scope for negotiation.

Shuffle Dependencies

If your deadline is constrained by dependencies, you can talk to project managers of the upstream and downstream projects to get a better understanding of the interconnections. You might be able to find a way to reorganise things and either get what your project needs delivered earlier, or move the deadline for your own project.

Be Smart About Compliance Deadlines

If you’re working on a compliance project, it may have a firm deadline established by the market bodies. In this case find out if there is a transition period. It is usually provided because market participants have differing levels of compliance and don’t have the same resources available to make the transition. You can also evaluate the impact of breaching the deadline (such as fines for non-compliance), and prioritise the parts of the project which would have the highest financial impact if they are overdue.

Double Check Estimates

When it comes to deadlines defined by estimation, it’s a good idea to double check the estimates. Ask what facts and assumptions were taken into account when the task was initially estimated.

Watch Out For Changes

Once the project starts, you have to watch out for changes in the project environment. Changes will affect project completion time, so work with the team and stakeholders to update the WBS and the schedule.

Organising Work On Projects with Fixed Deadlines

After you’ve applied the practices above and you are sure that you’ve done everything you can to negotiate a reasonable deadline for your project, the next phase is organising your work in the best possible way to meet the deadline.

I’ve found that the following practices help me complete projects on time:

Determine the business context which will be affected by the change to status quo
Define the scope of the solution required to satisfy the identified business need
Plan short iterations to verify the project direction
Align the solution with the existing business processes and IT infrastructure

Each of these practices is discussed in more detail below.

Determine Business Context

Completing this step successfully often determines the success or failure of the project.

Many organizations that operate in a competitive environment have well defined and standardized processes. Many others don’t however, so be prepared to discover them. Explore the business processes which may be affected by the new solution. Learn which systems are used by the business within these processes. Embedding new solutions into these business landscapes should be considered thoroughly to reduce resistance to changes and exclude redundancy in project management, solution delivery and transition to the new state. If done right, it also gives a business analyst an opportunity to find ways to add value to the business.

The rationale for the project should be identified by the project manager, while the business analyst should identify business drivers and actual business needs.

Define Solution Scope

This is the exciting part of the project, but defining solution scope has never been an easy task. Short timeframes and technological changes which may occur during your project make it even more challenging.

In general, to cope with this task the project team needs a solid foundation to build on – well documented processes and good infrastructure. Knowing and using best industry practices can often point you towards defining a sustainable solution and save exploration and research time.

When it comes to defining solution scope, my approach is to use only the “must” requirements for the “initial” solution, and prioritise the remaining “should” requirements into subsequent phased releases (“final” solution).

You must work closely with the solution architect and play an active role in exploring available options. Often the overlap between business analysis and system architecture saves a lot of time – I have saved up to a third of project time by ensuring that the architect could use my documents as a useful starting point in producing a detailed design of the solution.

Plan Short Iterations

I’m still on the fence with regards to the Agile method. Its value is clear in software development (at least for certain kinds of projects) but when it comes to business analysis, I’m not so sure. However, short iterations are one useful technique in Agile which can reduce project time. Use them to get a summary of the completed and outstanding tasks, evaluate changes to the project scope, and identify feasible shortcuts.

Project manager and business analyst need to present a unified front in dealing with business stakeholders. Face to face communication is essential to make short iterations work for analysing the current situation, required changes and making decisions on the next steps. Informal communication style helps too – really, there’s just no time for strict formalities if you want to get things done. It’s very important for the project manager to arrange a “green corridor” for access to authorities and clear the way for the team to focus on delivering rather than struggling with bureaucracy.

As a business analyst, you also have to do your share to deliver results quickly by being professional and active in all your activities (industry research, compliance requirements and so on). Make sure that communication is well maintained between everyone involved in the project.

Align Business and IT Infrastructure

Most of the time new solutions are embedded into the existing environment. It’s a good idea to make maximum use of the existing components and processes to make the introduction of the new solution less intrusive and to minimise the number of temporary patches and business interruptions.

I try to present the solution in terms of interacting services to achieve this. I transform business references to applications and systems into services and show how they could interact. This approach allows me to show the business users how all pieces of the business, including external parties and outsourced services, come together and how the new solution will improve overall efficiency.

Conclusion

Whenever you get a project with a short deadline, don’t forget that there are two major considerations: what can be done to change the deadline, and what is the best way to organise your work to meet the deadline.

The practices presented in this article should help you address each of these considerations.

Don’t Forget to Leave Your Comments Below

Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of innovative visual learning resources for business analysts. We think business analysis should be easy to learn! We deliver practical knowledge visually, with a minimum of text, because that’s an efficient way to learn. Find out more at http://aoteastudios.com

The Bad Ass BA Returns in Didactic Pentameter

Written by Cecilie Hoffman on November 9, 2010. Posted in Articles. 1 Comment on The Bad Ass BA Returns in Didactic Pentameter

The first annual IIBA conference, was conducted in Alexandria, Virginia in October 2010, entitled Building Business Capability (BBC). The conference was a collaboration between the Rules Forum, the Business Forum and the Analysis Forum (the IIBA). A collaboration – how perfect for a business analysis conference. Attendees were encouraged to visit talks in all three tracks and I feasted! I came to this conference in need of perspective, validation, encouragement, enthusiasm and vision, and came away with all that and more. For me it felt like someone had opened up a fire hydrant and unleashed a high pressure stream of quotable phrases and ideas.

The poem below is a distillation of the business analysis track of the conference. My apologies to people who are skillful in this art of iambic and dactylic meters (da dah vs. da dah dah). Read the poem out loud for the best result.

A is for Analysis

A is for analysis – differentiate and abstract,
yields requirements and rules from science inexact.

B is for business, whose capability we improve.
Maximize throughput? Just a step in our groove.

C is for change, for better for worse,

D is for decisions, or leaderless we curse.

E is for elicit, requirements fall not from trees!

F is for functional, remember non-functional, please.

G is for goals, stakeholders have their own,
non-overlapping, we lament and bemoan.

H is for how, counterpart of what,
a distinction so simple yet a knot hard to cut.

I is for iterative, cyclic nature pervades all,
yet management grips tightly to venerable waterfall.

J is our judgment project managers fear,
twin loyalties to business and to projects dear.

K is for knowledge we continuously accrue,

L is for listening which we actively do.

M is for metric, the chestnut is true,
that which we measure can be improved, can you?

N is for negotiate, can everyone agree?
Cross-functional monkey rodeo, that’s no way to be.

O is final outcome, our striving to delight
the blessed product champion who was our guiding light.

P is for process leaving nothing undone,
identifying hidden handoffs, one by one.

Q is for questions we have license to ask.
Assail those assumptions, take them to task!

R is for requirements, our stock in trade.
Oft mistaken for specification, please hand me a blade.

S is for scope, that game of ping pong,
one stakeholder to go,will the decision last long?

T is for trust, partner of integrity.
Armed with the pair, analysis proceeds intrepidly.

U is for users whose lives we make better,
improving usability or efficiency unfetter.

V is for validate and verify, they are different you know,
but it’s value, true value that analysis shows.

W is for who, what, when, why and where, the pentagonal key
that unlocks preconception setting ideas free.

X is for executive whose sponsorship we seek,
facilitating these folks is not for the meek.

Y is for yes, magic word of approval.
Can it be heard without a tribunal?

Z is for zilch, either missing or unknown,
the truth will emerge once the seeds have been sown.

* * *

But what about all the other words I could have chosen? I’m so glad you asked! Here’s the lexicon I started with; I challenge all of you to write your own poem and have fun! I would love to see what you come up with.

A agility, action, automate, analysis

B business

C constraint, committee, consistent, compliance, communication, change

D data, deliverable, decision

E efficient, effective, elicit

F functional, non-functional, facilitate

G governance, gathering, goal

H how

I issue, IT, impact, implement, initiative, influence, iterative

J judgment

K knowledge

L list, leverage, listen

M manage, methodology, metric, missing, measure

N negotiate

O operations, objective, organization, outcome

P production, project, product, process

Q quality, questions

R risk, rule, research, record, ROI, relationship, requirement

S success, structure, support, SME, sign-off, supplier, solution, system, specification, scope

T tools, training, terminology, test, TBD, trust

U understanding, use case, unknown, user

V voice of the customer/data/IT, version, vocabulary, verification, validation, visible, value

W work breakdown structure, who-what-when-why-where

X execute, excellence, executive (cut me some slack)

Y you, yes

Z zero, zilch

Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She authored the 2009 Bad Ass BA series for BA Times. See her blog on her personal passion, motorcycle riding, at http://www.balsamfir.com. [email protected].

How a Business Analyst Becomes an Advocate

Written by Kupe Kupersmith on September 27, 2010. Posted in Articles.

If you know me, you know I make it clear that building relationships is one of the most important skills of a business analyst. By building strong relationships with your stakeholders you become an advocate for the business and your project team. But, how do you build these relationships? How do you become an advocate?

In April of this year I started doing an improvisation workshop for business analysts called “Business Analysis through Improvisation”. If you read my earlier post, “Improv Comedian Turns Business Analyst“, you know I regularly performed with an improv troupe for many years in Atlanta. In the workshop, I discuss and demonstrate improvisation rules and guidelines that I feel help the attendees be better BAs.

Here are two rules that I cover in the workshop that I want to highlight here. These rules will help you build strong relationships so you’ll be viewed as an advocate.

Keep Conversations Moving Forward

I covered this in my earlier post, but I felt it was important to bring this up again. In improv, as you probably know, there are no scripts. The same is true for business analysis. I can bet you never have a word for word script ready that you use in your conversations and interviews with stakeholders. Because there are no scripts, in improv you can never “deny” the other actor. If an actor says something to you, you have to accept what they say and add to the conversation. You never outright say no. If someone walks into a scene and exclaims “Wow, I love that you colored your hair yellow,” you never say “it’s not yellow.” That denial instantly puts the burden back on the other actor to come up with something else. It kills the scene and ends the conversation.

In business analysis, for example, our business stakeholders come to us with changes in scope. If you always say “No, sorry that was not in scope”, you are out right denying. You end the conversation with the stakeholder. You may think you are ending the discussion about new scope all together, but all you did was make the stakeholder mad. He’ll just escalate and talk to your PM or manager to try and get the new items in scope. Does this mean you should say yes? To be an advocate and build a strong relationship, you don’t have to say yes, but you need to go with the conversation. In a situation like this, after clarifying the need I’ll say something like “we can definitely add that feature, let me work with the team to see what the impact on the cost and schedule will be. Then we can discuss if you still want to include it in this release.” Doesn’t that sound so much better? You keep the dialogue moving forward. You come across as a team player, as an advocate. By not denying you help everyone make an informed decision on how to move forward.

Another example, when you can deny is when a stakeholder comes to you with a solution. In business analysis we are taught to understand the root problem or opportunity before jumping to a solution. Often, the business stakeholder comes to our team with a solution. A denial type response would be something like, “Let’s not talk about the solution before we have had time to understand the true business need.” Should you discount their solution option? Do you assume they have not done the business requirements for the project? Instead you can respond by saying something like, “Great, tell my why you need that solution.” By starting the conversation that way you’ll get the answers you need and be able to help the business address the problem or opportunity with the right solution.

Be in the Moment

Since there are no scripts in improve, you need to be completely focused on what is happening on stage. You have to be a true active listener. If you are not in the moment, you’ll miss words and signals from other actors on the direction of the scene. It becomes apparent real quick if you are not in the moment. You’ll say and do something that makes no sense.

There is plenty of talk that we need to be active listeners and be in the moment. Business analysts are communicators, we are great listeners. But, how many of us are really great active listeners? It is not all our fault, society is against us! Things like instant message, email, a smart phone at your hip, back-to-back-to-back meetings, and a full plate at work and in your life make it easy for us to be distracted. What happens is we are always multi-tasking. Women, historically, are the best multi-taskers. This goes back to the hunter-gatherer theories where men were the hunters and had to be singly focused on the animal they were going to kill that day. Women were the gatherers, collecting fruits and vegetables, taking care of the kids, and the home. There is a great one man play called Defending the Caveman that explains this theory in a very funny way.

One of the biggest relationship killers is not being in the moment. How do you feel when you are having a meeting with your manager about an issue you’re having and he is multi-tasking; checking his email or asking you to hold on while he takes a call? I know I would feel like he doesn’t really care much about helping me with my issue. This is what your stakeholder will feel like if you do the same during an elicitation session. If you felt it was important enough to schedule the meeting, then focus on that meeting. Act like a hunter and focus only on that meeting. If other important activities need to be addressed, it is better to reschedule the meeting then keep interrupting it.

Keeping conversations moving forward and being in the moment are two ways to build strong relationships and be viewed as an advocate. Continue to work on these areas.

To your relationships!

Kupe

Don’t forget to leave your comments below

Managing Up; Tips and Tricks for the Project-Challenged

Written by Fred on August 31, 2010. Posted in Articles.

Managing Up is Vital

If you are a busy business analyst or project manager or even if you combine both roles by necessity, you already know from experience that “managing up” is a big deal. Failure to influence your boss’s boss, sponsors, and anyone else more senior to you to pay attention to important project details and give you their buy-in and commitment can have very serious consequences. You, your team, your organization, and your customers risk lost time and money, scope creep, poor quality results, lower innovation, reduced productivity, and higher levels of stress and burnout causing delays and mistakes due to high turnover and absenteeism. The following six tips and tricks will to help the project-challenged who know that “managing up” is important and would like to be proactive in doing more of it better.

Managing Up is a Mindset: You are the Pilot
Imagine you are in the pilot seat in an airplane and you see a view of your project approximately 10,000 feet beneath you. Keep this “big picture” view in mind when you attempt to influence upwards.
You Have About 20 Seconds
All it takes if the first 20 seconds of a conversation with a boss, sponsor, or other individual more senior to you for him or her to gain or lose attention and interest. So use your time wisely by focusing on the most important things first, such as the outcome, risk, benefit, or issue. Leave the details for later.
Train Them to Say “Yes”
Ask questions that are easy for them to say “yes” to, such as: “Do you agree that we must meet our targets?” or “It is important that our internal customers have their requirements met, right?” When they say “yes” to questions about the big picture, you are actually training them to say “yes” later when you ask them to commit to more specific things. Gaining their attention and interest first is necessary if you want their commitment and action later.
Plan Your Message to Start at the End First
Start at the end first. State your recommendation or the results expected and identify related risks, options, or changes next. Remember that the other person is also a pilot and is looking at the project from afar. It is up to you to focus him/her on exactly what you need and want and once this is understood, you have done the ground work to address more specifics.
Train for the Marathon
If you were planning to run a marathon, you would probably not expect to reach the finish line without sufficient training and participation in shorter races. It is the same with managing up. You also need to train ahead of time to build stamina and experience. Prepare for the marathon experience of managing up by creating a managing up marathon training program consisting of short spurts of conversations that give you experience and help build confidence. Choose topics for these conversations that are not high-risk, such as asking for commitment to change a small part of a project or recommending a project change that has a positive impact on productivity or the bottom-line. Your goal is to prepare for bigger, more complex marathons requiring more stamina and confidence.
Practice, Practice, Practice!
Don’t restrict your training to actual projects. Find ways to practice “managing up” in your personal life as well. Create a list of people you can practice with, including: colleagues; friends; professionals outside of work. Try asking them for something, assuming they are senior to you. If you are a member of a professional association, club, or group, seek opportunities to influence others with more authority or seniority than you and then ask for their feedback.

Summary

Managing up is a skill as well as a mindset. It requires the perspective of a pilot, the ability to plan and deliver your key message efficiently, training yourself and others, and ongoing practice for success. Like anything else that is worthwhile, if you make the right choices about how to spend your time and energy to prepare properly, you have greater chances to achieve better results.

Don’t forget to leave your comments below

Dr. Gail Levitt is President of Levitt Communications Inc., a global organization in Mississauga, Ontario with affiliates in Vancouver, Ottawa, Montreal, and Boston. Gail is an accomplished author, facilitator, and coach, specializing in leadership communications, critical thinking, and problem solving. She has over eighteen years of success, leading and advising diverse teams in managing people and projects. Some of Gail’s customers include: RIM; Bell Canada; HSBC; Telus; ACETECH; Project World; ESI International; Sauder School of Business, UBC; ACETECH; Transport Canada; Canada Post; Toyota; Starwood Resorts International. Dr. Levitt is currently writing a book on team leadership for business analysts and project managers.

We Don’t Need BAs!

Written by Kupe Kupersmith on May 25, 2010. Posted in Articles.

Since you are reading this post I assume you are most likely a business analyst, want to be a BA, or have BAs working for you. At the end of this post I think you’ll all agree that we do not need BAs. I think it is also safe to say there is nothing positive about a BA.

Let me first define what I mean by “BA”. I do not mean a Business Analyst. I am referring to a Bad Attitude. I am a firm believer that we need business analysis, but we do not need business analysts with bad attitudes. Our profession is still young, and bad attitudes will seriously impede our ability to positively impact organizations around the world.

I recently went to a store to make a purchase. When I was next in line the cashier said, “Can I help the next person?” Her words were fine, but the tone was terrible. Her body language and lack of enthusiasm said “I don’t really want to help the next person in line, but that is what I get paid to say.” I knew this was going to be a bad experience, but I tried to approach it with an open mind. Unfortunately it only got worse. Here is an example of how I was treated. I had two items to pay for so I handed the cashier both. I quickly learned she was not happy about that move. She yelled, “One thing at a time!” I really like the store, but I had a really bad experience because of one person’s bad attitude.

In situations like this I normally don’t complain. I will just never spend my money at that establishment in the future. There are too many options out there. I don’t feel like trying to give feedback and help resolve the issue when I can just go down the street to the competition.

As a business analyst do you have a bad attitude? Let’s find out with this short quiz.

Answer the three questions below by choosing the answer that you most closely can relate.

When you are eliciting requirements for a specific process and your stakeholder starts talking about another process do you respond by saying something like:
a. “One thing at a time!”
or
b. “This is a great conversation, but we have time scheduled to discuss that process tomorrow. Can this wait until then or should do we need to explore this process before continuing?”
When your project manager asks for your status do you respond by saying something like:
a. “I’m working on it. I would be done if you didn’t keep asking me my status.”
or
b. “Things are looking good. I have a few more meetings this week. I’ll give you an update Friday.”
When your QA Analyst asks about a requirement for the third time do you respond by saying something like:
a. “I already explained this to you twice; I doubt a third time will help.”
or
b. “Let me see if I can explain this better…”

If you answered “B” to all of these most likely you have a positive attitude and are viewed as a team player and contributor. If you answered “A” to any of the above you may have a bad attitude. Think about why you answered “A” and you may want to make some adjustments.

Similar to my response at the store, the people you work with may not give you critical feedback about the impact of your attitude. They may choose to not work with you and decide to work with another BA without a BA (bad attitude).

Positively yours,

Kupe