Tag: Skills

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

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

Know When to Say When; How Not to Get In Over Your Head With Metrics

Written by Glenn R. Brule on May 18, 2010. Posted in Articles.

As business analysts we can agree that benchmarking is important, but from that point on we’re likely to find the conversation diverges. Differences abound in approaches of how and what to benchmark in order to prove value. Organizations become overzealous in what they want to benchmark and scorecard in their drive to create greater efficiencies. However, a key component for developing and monitoring successful metrics is ensuring that they are in alignment with the maturity of an organization. Knowing when to say when can enable less mature organizations to develop metrics that are both useful and appropriate at the developmental level.

Benchmark People and Process First

In a previous BA Times article on managing metrics, the author and my esteemed colleague, Keith Ellis, made the case for creating multiple point metrics for people, techniques, process, technology, organization and documentation standards. While creating multiple-point metrics may be the best possible scenario, it is an enormous undertaking and, given the maturity of an organization, the least likely possible scenario the organization can accomplish successfully. An organization that lacks BA maturity would do well to start with a simple approach to metrics that considers people, process and tools, with a greater emphasis on the first two.

I highly recommend forming a team of individuals to work together, ideally in a requirements workshop setting, to determine the metrics to be monitored. Select a maximum of five things to measure for a benchmark. Keep in mind that the metrics don’t have to be exact. A “swagged” or estimated number calculated with simple mathematics and a plus/minus degree of accuracy can be used when there are no specific data elements readily available and should be acceptable until a level of maturity is reached. As the organization begins to mature, so too can the details being measured, the formulas used to calculate those measurements and the accuracy of the metrics.

Processes are interdependent and complex, so restrict yourself to three to five processes. Basic measureable process-related activities could include such items as time to complete an iteration, number of change requests and total number of iterations. Also, look at the solution development lifecycle and pick one or two that are bleeding the most. Finally, schedule benchmarking on a monthly basis. One year out is too late for a remedy, and with fewer metrics to benchmark, you will find the task is quite manageable.

Tools really shouldn’t play a role in developing and monitoring metrics, but they invariably do when an organization begins to cloud and confuse what level of metrics should be assessed. It’s important when using this simple approach to remember that knowledgeable people and refined processes are needed before you can select a tool. A tool is only as good as the people and process using it. A simple SWOT (strengths, weaknesses, opportunities, threats) analysis will help a team to quickly ascertain appropriate people and process metrics.

Scorecarding Metrics

Scorecarding is very important for measuring how well activities are being executed and individuals are performing. It should be related to goals and objectives and show a demonstrated relationship with benchmarking to people and process (and tools, if they’ve somehow gotten into the mix). However, scorecards are often put in place and not used because they’re so complicated or they don’t relate back to benchmarks.

Even in singular projects, scorecarding should focus on one to three things. Take, for example, two or three benchmarks that would be measured for running a requirements workshop. One workshop iteration takes 40 hours of effort for planning, execution, validation, etc. The next workshop is conducted after training people and reduces the workshop effort to 20 hours. The scorecard would indicate a 50 percent increase in efficiency.

Project Comparison

Side-by-side paired project execution has the potential to be a valuable benchmarking tool, as long as it doesn’t become too burdensome or complex. Keep in mind that no two projects are identical so give yourself some leeway in finding comparable projects. For instance, a $100,000 project could be benchmarked against a $150,000 project. Then, follow two or three things from project to project and be prepared to evaluate five to ten projects that are similar in nature.

Ongoing Reviews

Peer reviews, contract reviews and structured walkthroughs can increase efficiencies more effectively than look-back reviews conducted after the fact. The reviews should be done through the entire process as iterative functions so that by the time you’ve gotten through a project, you should be confident in your scorecard data and benchmark comparison.

Toward Positive Financial Impact

As an organization matures, overall project costs, return on investment, internal rate of return and the time spent on validating output of interviews, requirements workshops and other BA functions will build toward performance improvement, not only for individual projects but also for project portfolios. This will enhance the value of business analysis and the positive financial impact that can be realized. An organization that lacks in BA maturity should take a simple approach to measure its performance. When it comes to requirements metrics, don’t try to run before you can walk.

Don’t forget to leave your comments below

Glenn R. Brûlé, CBAP, CSM, Executive Director of Client Solutions, ESI International brings more than two decades of focused business analysis experience to every ESI client engagement. As one of ESI’s subject matter experts, Glenn works directly with clients to build and mature their business analysis capabilities by drawing from the broad range of learning resources ESI offers. ESI, a subsidiary of Informa plc (LSE:INF), helps people around the world improve the way they manage projects, contracts, requirements and vendors through innovative learning. For more information, visit www.esi-intl.com.

The BA and PM Role; a Deeper Dive

Written by Elizabeth Larson on February 23, 2010. Posted in Articles.

In November I wrote about whether or not the roles of PM and BA could be combined into one. I received wonderful responses, all of which broadened my perspective. Although I remain convinced that in most circumstances both roles are preferable, I understand that certain conditions, such as project size and corporate culture, may dictate whether or not one person plays both these roles on the same project. Another factor is that from a high-level view the skills seem similar. However, once we dive deeper into the business analysis and processes, the overlap lessons.

Today I’d like to explore the amount overlap between the two roles somewhat more deeply. Because of the need to use a common set of terms, I’m going to base my discussion on the Knowledge Areas (KAs) found in both the BABOK® Guide 2.0 and occasionally refer to the PMBOK® Guide Fourth Edition. Let’s start with the BABOK® Guide’s KAs. A mnemonic to help remember the KAs is PEACEUS. Think of all the “pieces” in the BABOK® Guide. PEACEUS stands for:

	Knowledge Area	Knowledge Area Highlights
P	Business Analysis Planning and Monitoring	Just for the business analysis phase(s): determine if the project will be waterfall or agile, identify stakeholders, estimate activities, decide which processes to use, determine metrics, monitor business analysis work.
E	Elicitation	Prepare for elicitation event, hold the event, document and confirm the results.
A	Requirements Analysis	Organize, prioritize, specify, verify, and validate requirements, including modeling requirements.
C	Requirements Management and Communication	Baseline requirements, manage changes, trace requirements, document requirements, present requirements for approval, manage re-use.
E	Enterprise Analysis	Define business need, assess gap between “as-is” and business need, determine how to approach the solution (“to-be”), define the scope of the solution, and develop a business case for undertaking a project to meet the business need..
U	Underlying Competencies	Qualities, knowledge, and skills that business analysts need to have to be successful, such as trustworthiness, systems thinking, ability to negotiate and communicate, and business knowledge to list a few.
S	Solution Assessment and Validation	Determine if the organization is ready for the change, figuring out how to implement the change, and allocate requirements to different projects, phases, releases, or iterations.

On the surface it appears that there are significant overlaps. For example, collecting requirements appears to be an area where there is confusion over roles and the potential for conflict. Another area is that of procurement, particularly relating to the Request for Proposal (RFP) processes. Another area for role overlap and conflict is scope management. Enterprise analysis is about defining the solution (product) scope. The PMBOK® Guide describes the need to detail out the scope of the product and the criteria needed to accept the product.

It seems to me that although there are areas of potential overlap, there are some significant areas that require unique skills. The table below shows some of the areas of overlap and uniqueness.

	Knowledge Area	Areas of Overlapping Skills	Requiring Specific BA Skills
P	Business Analysis Planning and Monitoring	Identifying stakeholders, defining activities, estimating activities, developing metrics, monitoring the work.	Determining if the project or phase should be waterfall or agile, planning the processes needed to complete business analysis.
E	Elicitation	All these areas potentially overlap. Many of the skills are required by both the PM and the BA.	Skills for eliciting some requirements activities require a different skill set. For example, if the elicitation event is to prototype a new set of web pages, create use cases, or elicit data requirements, specific business analysis skills are useful.
A	Requirements Analysis	Not too much overlap. This area does include defining assumptions and constraints, but it’s a stretch to say there is much overlap here.	Organizing project work is very different from organizing and prioritizing requirements. Specifying requirements, which is where the modeling happens, for example, requires a specialized skill set that doesn’t overlap with those of the PM.
C	Requirements Management and Communication	There are many overlapping communications and presentation skills.	Although baselining, documenting, and tracing requirements are discussed in the PMBOK® Guide, I believe that it takes unique business analyst skills to effectively complete these activities. Also, managing re-use is a unique skill.
E	Enterprise Analysis	Defining the solution scope requires similar skills to decomposing deliverables into a work breakdown structure (WBS).	After much agonizing about this one, because this was work I did as a PM, I can be convinced. Except for defining the solution scope, all the processes in this KA, can be more effectively handled by the BA,
U	Underlying Competencies	All project professionals, both PMs and BAs, need these competencies.
S	Solution Assessment and Validation	Assess organizational change.	With the possible exception of assessing organizational change, this KA requires a unique set of skills to determine if “the solution meets the business need and facilitate its implementation” Babok® Guide introduction to Chapter 7.

I believe that if we were to take these processes within each KA down to the tasks within each process, we would see even more uniqueness. So for now, I continue to think it best to separate the two roles where possible.

Don’t forget to leave your comments below

Will the Real BA Foundational Skills Please Stand-up

Written by Kupe Kupersmith on February 16, 2010. Posted in Articles. 1 Comment on Will the Real BA Foundational Skills Please Stand-up

An interesting discussion was started on a LinkedIn group a few weeks ago posing the question, “What would you think is the single factor that determines project success?” This sparked a healthy debate and made me think on a more micro level for business analysis. I asked myself what are the foundational skills needed by a business analysis professional? It did not take me long to answer my own question. Let’s see if you agree.

Let me start with what I think they are not. In our profession it has been discussed that at a minimum, BAs had to know the accepted techniques used in the role. Examples include use cases, workflow diagrams, context level data flow diagrams, etc. These are critical pieces to making an excellent BA, but not the foundation. They are interchangeable and new ones can pop up at any time. Did people not analyze before use cases became a standard format for analyzing and documenting requirements? Sure they did. These techniques are not a constant.

Analogy time! Let’s consider a house. The foundation is solid (hopefully). It supports the living space of the home. The living space is filled with appliances, furniture, art, rooms with doors, closets, windows, etc. Depending on what you are doing in your home at any time, you use some rooms, some furniture, and maybe an appliance. At the same time rooms, furniture, and appliances are not being used. Then there is the bread maker you were given for a house warming gift. That baby only comes out during special occasions. The rooms, furniture, and appliances are the equivalent to the techniques I mentioned earlier. The techniques are used when necessary. Every project does not require the use of every technique you have available. So then, what are the real foundational skills you need?

When I think of a foundation, I think of something that is constant, always there. Your foundation needs to be built with trust, analytical and problem solving skills, mixed with ethics, personal organization, business knowledge, and communication and interaction skills. These are often referred to as soft-skills, but these are nothing close to being soft. This is your foundation. From here everything is possible.

In the IIBA BABOK these skills are called underlying competencies. The writers of the BABOK define these as “the skills, knowledge, and personal characteristics that support the effective performance of business analysis.” The writers got it right by using the words “underlying” and “support”. Without these skills BAs cannot perform at their peak, just like a beautiful front door that won’t open or close properly because of a settling foundation.

Knowing the technical aspects of the techniques available to you is not enough. Even if you know the when to use an Activity diagram and all the symbol definitions, it is useless if your foundation is not secure. What good is that technique if you don’t have the interaction skills to elicit the requirements, or the communication skills to ensure you understood the requirements, and the ability to ensure the solution team clearly understands the need.

Take a few minutes and inspect your foundation. Is it secure?

Foundationly yours,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].