Tag: Planning

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

Where Do User Stories Come From? Part 2

Written by Robert Galen on November 9, 2010. Posted in Articles.

In my last post I introduced the topic of User Story Writing Workshops. These are planning meetings where a product owner can gather a team (existing or potential) together where they collaborate to create a list of user stories to be used in seeding a product backlog.

It’s a wonderful technique for generating loads of stories-quickly! It also has some serious side-benefits that I think are valuable as well. But, enough of that…

Let’s Get to Writing Stories

There are many ways to attack story writing in groups. I’ll be emphasizing my preferences here, but don’t let that limit your own approaches. The key element is to:

Generate as many stories as possible
Across as broad a spectrum of features / work as possible
As quickly as possible
And along the way, collect as much Meta-Data as you can

I like to have the roles drive the brainstorming, so for each role, I’ll allocate 10-15 minutes of story writing time. Usually, I start this with the entire group-so everyone is writing. I’ll “call out” each story as I collect it to let everyone know what’s being written and to reduce the number of duplicate stories produced.

Once you have a large set of stories, I like to stop action (writing) and get the team engaged in “cleaning up” the stories. If I’ve posted them on a whiteboard, I’ll invite the entire team up to the board to start removing redundant stories, consolidating stories where there are obvious relationships, and writing new stories to fill in any ‘gaps’.

Often I’ll oscillate between writing as a group and this collaborative clean-up effort. It helps to keep the whole group engaged in the process and it maintains energy and focus in the meeting. Once you’ve developed stories for each one of your roles, you’re essentially done with “Round #1”, Then you move onto massaging (ordering in time sequence, considering risk, filling in gaps and dependencies, etc.) in your stories.

The Chess Analogy

Once you have a fairly healthy list of stories, I like to spend a fair amount of time on ordering them. This gets everyone thinking as soon as possible about execution. And because we’re thinking of overall workflow instead of pure feature development, another rich set of stories soon emerges related to things like quality and testing, release preparation, design and architecture, prototyping, UX design, software packaging, etc. You know, all those things required to get the project ready for customer deployment need to be captured in story-form as well.

In order to do this, I ask the team to place the stories in largely three buckets: opening moves (early stories), middle game (middle – mostly execution based stories) and end game (stories focused towards completion and delivery).

While this is truly not a WBS or Gantt chart, it does serve to get the team organizing the story mix into a rough workflow and begin thinking of linear dependencies and breaking things down for construction and integration. So the flow is illustrated below-

Overloading Your Stories, Meta-Data

Perhaps it’s just me, but if I’m taking time from a team for a story writing workshop, I want to maximize the data that I collect. To do this I usually ask the team to overload their cards with other bits of useful information that I might (keep in mind might) use later. For instance; Adding estimates, in either weeks or story points, can be a useful exercise at this point. This becomes the starting size estimate for each story and even though it’s simply a guess, it does help to communicate size and level of effort across the group.

Another thing to consider is team assignments, especially those for any specialized skills. For example, if there’s a database story that the entire team knows only Sally can effectively handle, then we might say that on the card. Or if the card requires a skill that we don’t currently have on the team, then specifically identify that gap.

I try to avoid any notion of “tasking assignment” at this point, so don’t do this for every story. Just mine these connections as a natural consequence of the writing.

Related to this point is the notion of capturing dependencies and risks. Again, we’re just writing our thoughts down on Post-it Notes, so ask the team to note cross-story dependencies right on the Post-it Notes. You should also visually orient the stories to be “close together” on your board. And while the team is collaborating, I always ask them to identify risks as they go along. I usually maintain them as a growing risk-list off to the side.

I find that this sort of meta-data gathering enhances the quality of the workshop, but also reduces the time it takes for later processing of the stories into a Product Backlog. This data can be equally valuable as the stories themselves.

Finally, What’s Next?

Once I have the “opening move” stories defined, I usually will ask the team to do a bit more detailed expansion around these early stories. The logic goes that while I have your time and attention, why don’t I leverage it a bit more to increase the depth of visibility into high priority stories. This also serves to set the stage for “next steps” immediately following the workshop. So dig into the details on your highest priority stories.

Wrapping Up

So there you have it! By investing perhaps a half day of time, you can come out of a User Story Brainstorming Workshop with a wealth of information. You have stories. You’ll have a view to workflow, what needs to be done right away, and what’s deferrable. You’ll have a sense for key skill stories and for dependencies and risks. And you’ll have a solid view towards next steps.

But most importantly, your team will have created a “shared view” of their overall project. I’ve found this outcome to be critical when the team starts to iteratively attack the work. Since everyone contributed collaboratively to the overall scope of the project AND contributed to workflow details, they’ll have an innate sense of what is needed and where things are headed.

How cool is that?

Don’t forget to leave your comments below

Requirements Definition Phase – Are We Done Yet?

Written by Cheryl Hill on March 30, 2010. Posted in Articles.

People often ask me “how do we know when we are done with the requirements phase?” My opinion? You are never completely done with requirements but criteria do exist by which you can assess the completeness of your requirements and gauge your readiness to proceed with design.

Criterion 1: Let the Scope be Your Guide

Okay, my assumption is that your project has a defined Scope. You know, that’s the document you produce at the outset of the project that serves as the foundation for writing requirements. As a refresher, the components of Scope are:

Need: The problem you are trying to solve or the opportunity you want to exploit
Goals: Things to accomplish to meet the need
Objectives: Criteria for success
Interfaces: External entities (people, processes and systems) that will send inputs to, or receive outputs from, your product
Drivers and Constraints: For example, regulations, standards, existing systems used with your product, higher level requirements, schedules, budgets, stakeholder expectations
Operational concepts: These are stories or scenarios that describe a day-in-the-life of your product for different lifecycle phases (e.g., operations, transportation, installation, maintenance, storage, manufacturing, disposal) from different stakeholder viewpoints

Every requirement you write should be in response to one or more components of the project’s scope. If the requirement does not help you meet the scope, you probably don’t need it. This said, look at the components of your scope and ask yourself, have you defined the requirements necessary to meet the need, goals, objectives, interfaces, drivers and constraints? Have you documented all the requirements that you derived from the operational concepts? If you answered yes to all these questions, you may be ready to baseline your requirements and proceed to Design, but just to make sure, I recommend that you apply additional criteria.

Criterion 2: Look at Your Models

If you developed models using business process, object-oriented, or structured analysis techniques, then you have on-hand a great way to verify that you have a complete set of requirements. When I speak of models, I am referring to Activity Diagrams, Swim Lane Diagrams, Flowcharts, DFDs, ERDs and the like. I am a staunch advocate of modeling. Developing models is a great way to engage the stakeholder and get them to communicate their requirements in a non-intimidating and comprehensive way. By non-intimidating I mean- how scary is it to draw a picture to graphically present what is done today or that which is wanted in the future? Comprehensive? With a picture, you can easily validate steps and decision points and identify errors and omissions.

When I assess the completeness of my requirements, I prefer to work from both my current state and future state diagrams. By analyzing both states, I increase my confidence level that I have the requirements to sustain existing function, performance, and compliance needs as well as define the requirements essential to achieve the defined Vision and scope.

Criterion 3: Look at Your Template

Did you use a standard outline or template for your requirements? Many organizations have developed standard templates for different type of projects…hardware projects, software projects, maintenance, upgrades, etc. A well-constructed template lists the different types of requirements that are typical for the various types of projects/products of an organization. So, if you use a template, make sure that all relevant requirements have been gathered and documented. Excuse me for stating the obvious but a big hole in your template is a pretty good indicator that you are missing some requirements.

Criterion 4: Conduct a Requirement Review

I know…the dreaded review…with your gasp stakeholders!!! But you know, a requirement review does not have to be a horrifying experience and it really is the best way to ensure that you have a complete set of requirements.

Follow these simple rules and the pain you associate with the requirement review will be minimized:

Make sure the requirements document is ready for review. Correct all typos, grammar problems, punctuation errors. Also, make sure that all requirements are written according to the rules for writing good requirements. We want people to focus on the content, not stupid little errors!!
Include all project stakeholders in the review. I also recommend that you invite knowledgeable people from outside the project to gain perspective of those not so intimately involved in developing the product requirements. These outside “experts” need to be technically competent and have worked on similar development efforts.
Make sure that all reviewers understand the Scope of the project. If people are reviewing the requirements with no concept of the Vision, of the scope, you are wasting everyone’s time.
Conduct a Review Kickoff Meeting prior to distribution of the requirements document. In this meeting, presentation topics include:
- Purpose of the review
- Expectations of the reviewers
- Rules for the conduct of the review
  - Criteria for the review
  - Standards
  - Templates
  - Review comments
  - Feedback
- The project scope
- Other information you feel the stakeholders need to successfully perform their review tasks

The intent of the requirement review is many-fold:

Identify and correct errors and omissions
Confirm the correctness and completeness of the requirements
Obtain buy-in and agreement from all stakeholders
Set expectations
Get sign-off

Criterion 5: Cost/Benefit

Okay, I admit, regardless of what you do to validate you are done with the requirements phase, you still have those “hand-wringers” that refuse to sign-off for fear you are missing some really important requirements. You think you have all the requirements, the majority of the stakeholders think that you have all the requirements, but you, and probably everybody else, secretly want a single one indicator that screams that you have all the requirements and are ready to baseline and start designing. Sorry, no such indicator exists. If you are in a quandary about whether you are done with requirements or not ask yourself this question…

What will cost less – potential downstream changes because I forgot some requirements or the time, schedule and resource investment required to make sure that I have defined every possible requirement?

A word of caution; there are people who are on the other side of the spectrum from the hand-wringers…I call these people the Schedule Mongers. Schedule Mongers are those who insist on starting the next phase of a project irrespective of the status of the current phase because “see it’s on the schedule and if it’s on the schedule, we have to start!!” When assessing the readiness to move to Design, the Schedule Monger does not necessarily care if the requirements are done and is oblivious to, or in denial of, the fact that starting without a good set of requirements will definitely cause a slip to the product delivery, add costs, and probably result in unsatisfied customers. So beware the Schedule Monger and know that the question you ask about the risk (cost) of proceeding, or not, is just as applicable when dealing with the Schedule Monger as it is with the hand-wringer.

Conclusion: Are We Done Yet?

Ludwig Wittgenstein stated “The riddle does not exist. If the question can be put at all, then it can also be answered.”

Hmmm…I suspect that Ludwig never had to deal with requirements!!!

You will never be done with requirements because things change – businesses change, technology changes, competition changes, people change. And, it is because of this inevitable change I feel that the question “When do we know we are done?” cannot be answered with 100% confidence.

However, if you assess requirement completeness within the confines of:

your defined scope,
the developed models
your organization’s comprehensive requirements document templates; and
you enlist your stakeholders’ participation to confirm a comprehensive and correct set of requirements; and
you evaluate the potential costs of future changes with that required to foresee every requirement,

then you can answer that question we often hear during the requirements phase – are we done yet?

The answer??

No we are not done yet but we are done enough to proceed to design.

Don’t forget to leave your comments below

Cheryl Hill, PMP is Chief Operating Officer and senior instructor for Compliance Automation, Inc., a leading provider of requirements training and other services to help companies, government organizations, and individuals produce defect-free requirements in the most efficient and effective manner possible. Cheryl, along with all of CAI’s trainers/consultants, brings to the classroom 20+ years of real experience in project management, requirements and other areas of system engineering and business analysis. Since 1990, over 25,000 of our customers have looked to CAI for pragmatic approaches to analyzing and managing scope and requirements. At CAI, we deliver training to our customers that is necessary and of value to the individual and the organization, long after the training is complete. For more information, call us at 830-249-0308 or visit us at www.complianceautomation.com.

Free, Easy and Powerful Tool – the CBAP 007 Scope-O-Matic!

Written by Marcos Ferrer on February 16, 2010. Posted in Articles.

Just in case any of my readers think I (yes, I am CBAP 007) am only good for political analysis, I offer a simple BA “tech” goodie (our tech is different from their tech – this one works with paper and pencil, in a pinch!).

If you have ever been in a project where scope keeps wandering, even after endless discussions, just use the 007 Scope-O-Matic to sort it out in your mind. Once this is done, it will be easier to sort it out with the stakeholders.

Don’t write me telling me that this is the project manager’s responsibility – the project manager doesn’t face confused stakeholders day after day. Sometimes the PM acts like another stakeholder, announcing scope as if no one else could understand or discuss it. Often it is not in fact understandable, usually because it is oversimplified, and discussion is not welcome.

The secret is in not oversimplifying the scope (“To do requirements for a new order entry system” is not clear at all) and putting good boundaries on the problem. It is not enough to say what is in scope – often what is in scope “implies” other issues, not made explicit, yet leading to multiple confusing meetings.

Now, with Scope-O-Matic, you can identify more detail in your scope, and you can identify what is out of scope, and what is ambiguous in scope, as well as what is in scope.

If you have never tried this, you are in for a treat. Even if those around you never do sort out the “true” scope, you will have a lens into the confusion, one that will help you keep your head, while all around are losing theirs.

Have fun, let me know what happens. Even five minutes with this tool will teach you things that you know but hadn’t articulated – it is a great “gap” analyzer – do it for your project today!

Keep the discussion coming, here is your free tool!

IN and OUT of SCOPE, with “Possible Ambiguities”

IN SCOPE	???	OUT of SCOPE

Build a Prototype system	Creation of a Prototyping Demo Environment?	Creating an application environment.


Creation of a Prototype covering Order Taking, Picking and Shipping	Electronic orders or just phone orders? Faxes?	None of the marketing that leads to a customer making an order


Elicitation of user interface and functional requirements using prototype	Capture or dispose of business rules discovered during elicitation?	Elicitation of software, security, reliability or any other non-functional requirements

Documentation of functional Requirements and user access privileges	Are user access privileges a part of security requirements?	User or programming guides, response time requirements, system uptime, system scalability, etc.
Screen shots (in documentation)	The screens have over 15,762 permutations, if you count menu views – how many screen shots?	Functioning code of any kind
Process (functional) requirements (use case model & text)	Level of detail?	Traditional FRD non-documentation
Assumptions made by requirements team	How to bridge critical “unspeakable” assumptions?	Assumptions that are “unspeakable” yet critical


THE REST	IS UP	TO YOU

Have fun!

Don’t forget to leave your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

The Business Analyst’s Guide to Dealing with Difficult Sponsors

Written by Dana Brownlee on January 5, 2010. Posted in Articles.

Part of the challenge that the business analyst faces is the reality of having to serve so many different stakeholders and sometimes being pulled in very different directions. We’re often taught that our sponsor is the person who is the champion of the effort. Indeed, they are often the one we’re to seek out for support and issue resolution throughout the project. But what do you do when your sponsor is the problem??? As I travel the country and beyond to speak to business analysts, project managers, and team leaders about how to best manage problem attendees in their meetings or deal with difficult team members, I am astounded by how often someone raises their hand to ask, “But what do you do if your sponsor is the problem?” I have to admit that that does pose an interesting dilemma, but it’s not one void of strategies you can use to address this not too uncommon problem. Let’s explore a few different varieties of the difficult sponsor and see how they can be managed for optimum success.

Sponsor Type 1.

I hope you don’t mind me intimidating everyone with my overbearing nature at your team meetings…I’m just trying to help you speed things along J.

Sometimes the problem is getting the sponsor to show up for meetings as requested. On the other hand, sometimes we’re sorry they did show because they become our problem participants and that can be difficult to manage. Try these meeting facilitation techniques:

Meet with the sponsor prior to the meeting and specifically discuss what you need from them in the session. Possibly write out talking points for them – many will appreciate it if it’s offered in the spirit of helping take one more thing off their plate (not telling them specifically what to say). Ask them to withhold their opinion until others have weighed in to avoid tainting others’ input.
If you sense others may be intimidated by the sponsor’s opinion, suggest the group do a round robin and start at the opposite end of the table to the sponsor (so that their opinion comes near the end).
Stand up! Whenever you stand when everyone else is seated, you immediately regain control of the group (temporarily). Thank the sponsor for their input (even note it visibly) and redirect the conversation as needed.
Repeat their point and write it down – this may sound counterintuitive, but oftentimes a sponsor will get on their soap box (and not get off it!) because they don’t feel heard. When you repeat the point back to them and then write it down for all to see (on a flip chart or whiteboard), it reassures them that they have indeed been heard and immediately communicates an appreciation for their point.
Ask for solutions – sometimes meeting participants (even sponsors) get caught in a cycle of whining and venting about problems. After agreeing with the issue (if appropriate or not, offering an opinion if you don’t agree), simply ask the sponsor to suggest a solution. Insist that the issue being raised is important enough to warrant devoting some energy to focusing on a solution.

Sponsor Type 2.

I’m not exactly clear on what I’m looking for, but I’ll be sure to hold you responsible when I don’t get it…

Clarify the effort early and often. Identify in scope items and out of scope items (out of scope is critical), tangible deliverables, timing expectations, budget restrictions, roles and responsibilities, known risks, and key stakeholders.
Identify their soap box issue early and emphasize WIIFT (What’s in it for them). If they don’t understand exactly what they want, ask them to explain their motivation/driving factor. Often, execs have a soap box issue, predetermined bias, or hypothesis they want validated. Try to find out what this is as soon as possible.
Ask the sponsor to prioritize cost, time, and scope (good, fast, and cheap). Which is most important (relative to the others)? Hint: The answer is not all three. Think McDonald’s – their focus is very intentionally fast and cheap. Be clear which constraints are really driving the project.
Explicitly ask how they will define success. Always ask the sponsor to finish this sentence…I will consider this project a success if…

Sponsor Type 3.

Would you please boil the ocean? (and solve world peace too while you’re at it J)

Try to identify the specific mandatory requirements (and separate the “wants” from the “needs”). Sometimes they will ask for a Porsche when a skateboard will do. Also, there may simply be a knowledge gap and they don’t realize that there is a quicker, easier way to get them what they really want.
Document your risk analysis. Although we know that virtually all projects encounter problems, we usually spend little to no time analyzing risk before the effort starts. Don’t make that mistake! Assemble a few key stakeholders, brainstorm a list of potential risks, then estimate the likelihood and impact of each event. For each risk event, multiply the likelihood by the anticipated impact to quantify the severity. Add the severity of all risk events to determine an estimate of risk for the project. Here’s an example:

Risk Event Probability of Occurrence Anticipated Impact Severity

Supplier goes out of business 20% $1M $200K

Team loses key resource 75% $100K $75K

Inclement weather occurs 50% $200K $100K

Technology fails 20% $500K $100K

Total Estimated Risk $475K

Check with the sponsor to ensure he or she is comfortable with that level of risk (e.g. $475K in the example above). Also, ask the sponsor to help you come up with a back-up plan proactively (e.g. Jim, I know that if we lose our lead system architect, it will severely impact our timeline. In an effort to be as proactive as possible, I’d like to find out from you what we can do in the unlikely event thatt does happen?) Even if they insist that you proceed, your having documented these risks will be very valuable to you and the team. If you are proceeding, work with the team to prioritize risks and identify mitigation strategies and/or back-up plans for the most severe risks.

Remember the triple constraint – when they change one element, it impacts the others. If there is a reduction in time, emphasize the impact on cost and scope. (e.g. Jim, I understand that you now need to roll out the new release a month earlier than planned and we can do that, but there will be an impact on cost and scope. I can either reduce the scope and hold off on some of the features until the next release or spend about $50K more to expedite things. What is your preference?)
Push back if it’s not realistic…(e.g. Jim, I would be irresponsible if I didn’t tell you that I don’t think this can be accomplished with the level of quality we would expect. I know you would prefer that I be very honest now (before any time and money have been invested) rather than hear a laundry list of apologies after an unsuccessful project. I’d really like to be positioned for success, and I honestly have real concerns here).

Sponsors are supposed to be our protectors and oftentimes they are. Unfortunately, the difficult sponsor can make an already challenging project excruciating! Admittedly, dealing with a sponsor is a unique challenge due to the political realities, and there are no easy answers. Sometimes a difficult sponsor does not respond to reason and helps contribute to a very negative experience for the business analyst. More often than not, the business analyst is too intimidated to deal with the situation at all. Don’t make that mistake. Proceed with caution, use tact and diplomacy, be strategic, but do address the issue. The sophisticated business analyst can indeed manage many stakeholders – even the difficult sponsor!

Don’t forget to leave your comments below

Dana Brownlee is President of Professionalism Matters, Inc. which owns and operates www.meetinggenie.com, an online resource for meeting facilitation tips, training, and instructional DVDs. Her latest publications are “Are You Running a Meeting or Drowning in Chaos?” and “5 Secrets to Virtually Cut Your Meeting Time in Half!” She can be reached at [email protected].