Tag: Risk

The Magic Bus or Bustrophobia

Written by Steve Blais on April 17, 2012. Posted in Articles. 2 Comments on The Magic Bus or Bustrophobia

Back in the day, The Who, a British Rock group consisting of Roger Daltrey, John Entwistle, Pete Townshend and Keith Moon wrote and sang about a Magic Bus that would carry the singer to his girlfriend’s house. The Beatles another British Rock group of the time also sang of a bus on which a Magical Mystery Tour would roll on. And Paul Simon sang of looking for America on a cross country Bus. Ken Kesey took his Merry Pranksters across the United States on a Magic Bus and Tom Wolfe described the bus and tour in The Electric Kool Aid Acid Test. During the days of the nineteen sixties and seventies the bus metaphor was a positive thing.
Nowadays it is not the case, at least not in the IT world.

Today we have a Mysterious Bus that seems to prowl the roadways of IT searching to run over the best and brightest of IT workers. In project risk identification the bus reappears as an apparently valid concern as someone will ask, “What if our lead analyst were run over by a Bus?” It appears to be the same Bus that runs over these people regardless of where the project takes place. It’s a Bus that really gets around, targeting the more experienced members of the team or the members who have a specialized and usually irreplaceable skill. The Bus seems to be quite finicky as well, since it never takes after anyone but IT people.

In the agile world this Bus has earned a different status: the Bus Ratio. The Bus Ratio measures the number of people on your team who could be wiped out by that Menacing Bus without seriously damaging the project. The higher the ratio, the better. In other words, when a team has a high Bus Ratio knowledge and skill are shared among the team so that each team member backs up the others and is similarly backed up. In many traditional teams, the Bus Ratio is low signifying a tendency toward job security over team sharing such that if one person got hit by The Bus there would be a significant loss of organizational memory and skill set requiring a retooling of the team and an immediate call to the recruiters. The message of the Bus Ratio is clear whether you are agile oriented or not: share the ride.

What is interesting about the Bus Ratio is its application solely to the development team. The same team that is concerned about a high Bus Ratio among the team members, is adamant about maintaining only “One neck to wring” on the business side meaning one and only one Product Owner. The Bus has special radar that searches only for developers. There seems to be no concern that a Wandering Bus might happen to wipe out a Product Owner as collateral damage while hitting a developer head on. Either the agile community values the developers much more than the Product Owner, or they assume that the Product Owner’s knowledge is so common that anyone else from the business can step in after the Bus takes its toll.

That Bus is also apparently on call for the politicians on our teams and in our offices. When things start to go wrong, or “Go South” as the phrase is stated – which brings up another question: why would heading in a southerly direction indicate one is having problems? – someone decides to duck the blame or responsibility by throwing someone else “under the Bus”. The Terrorizing Bus will always happen to show up just in time for someone to be thrown under it. The assumption seems to be that once the unwilling team member is thrown under said Bus that person is not heard from again, lost perhaps in some metaphysical science fantasy plot wherein they become the Bus driver and seek other Bus victims.

Of course the one ducking the responsibility and throwing a compatriot under this Busy Bus might get caught and in that case the person is Bus-ted, an appropriate phrase all things considered.

So it is not surprising when a colleague in a agile team coaching role was recently met with silent stares when she used the phrase “we all need to get on the team bus”. She was referring to a sports team bus traveling to away games, especially in High School and College. The analogy was that if you want to play you have to get on the Bus; otherwise you are not on the team. A good analogy as long as the team members do not suffer from bustrophobia. (I did not make this word up. It is in the annals of psychology and relates to a perceived loss of control). It is hard to get people on a Bus when that Bus has been known to be cruising the streets waiting to run you down.

I should put in a bit of a disclaimer. Due to increasing pressure from those among us who feel that the Bus Metaphor is too negative – referencing violent death, for example – and the protests from the Bus Driver’s Union and various cities Public Transportation Departments who claim that Busses in general have a bad enough reputation, the new replacement metaphor to be politically correct is the lottery. The ratio becomes the Lottery Ratio which asks the question how many people on your team can win the Lottery and the team will still function? Of course this assumes that anyone winning the Lottery would quit their job and that the odds would allow for multiple Lottery winners. Then again, other than disallowing team members to cross the street there is no way to prevent the Itinerant Bus from striking the unsuspecting developer, but the organization can prohibit the purchase of Lottery tickets by members of the same team to reduce the risk of the Lottery Ratio. Of course I’m not sure if throwing someone under the Lottery makes sense to avoid blame, so another metaphor will be in order. Then again, when Gamblers anonymous hears about the Lottery Ratio, we will have to come up with another politically correct metaphor.

So the message is clear: to avoid bustrophobia keep BUSy, follow the syllaBUS, do roBUSt work, avoid aBUSive people, learn everyone else’s BUSiness for backup purposes, don’t combine comBUStible components, and most importantly: look both ways before crossing the street.

Don’t forget to leave your comments below.

10 Ways Analysts Can Contribute to Mitigating Risk

Written by Maryanne Miller on May 24, 2011. Posted in Articles. 1 Comment on 10 Ways Analysts Can Contribute to Mitigating Risk

Have you ever started a project without the formal contract? Have you been on a project without fully defined scope? As an analyst who has worked in various organizations and different industries, I can tell you that I have been in both those situations. Is that normal? No. In fact it goes against everything that the PMBOK and BABOK state are required input materials.

However, if you’re a new analyst working in the industry it can be confusing to know what to do and how handle these work situations since these are required input documents to begin work activities.

Below, I will share 10 tips on how BAs can assist with mitigating risks when faced with some of the most problematic business scenarios for Business Analysts. These suggestions also can really get a project back on track from an analyst perspective.

Business Situation

What you can do….

1. The contract is not finalized so the scope is still not defined.

After the formal project kick-off, start off the Requirements Project reviewing the assumed boundaries of scope. Secondly, clarify those original assumptions once the contracts are finalized and reset expectations if there were changes through change management procedures.

2. The Project Charter is not shared with the consulting BA team.

Project ‘SMART’ goals can still be established through means of elicitation either before the kick-off or during the first week of elicitation. This is as important as the scope to understand how the project success will be measured and should not be skipped.

Even if the goals are not SMART and measurable, obtain as much information as you can and include it in your discovery notes and documentation perhaps at a later date the client may be more open to re-addressing with you.

3. Requirements planning cannot be conducted prior to a formal Project Kick-off.

When the pressure is on to begin a project immediately after a contract signature and the time is not given for proper requirements planning, you can roll requirements planning into the project itself. You can conduct a joint planning meeting on their first day of the project and continue into the second (if necessary) with the clients while onsite prior to any elicitation activities.

This is a very important activity that can save time and iterations of unnecessary elicitation sessions by having the joint teams ready for each session and have a tactical approach. The time spent planning will save overall and this is the time to flex your influence and ensure that this critical step occurs.

4. Your organization does not have a Requirements Management Plan.

Many of the things that typically are handled in Requirements Management Plan also exist in the Project Methodologies. It is not uncommon for service organization to default to utilizing Project Management Planning or Methodology to cover areas such as:

Project Communication Plans
Conflict and issue management
Identifying Project Deliverables
Sign-off procedures for Project Deliverables
Change Control Process

What you will need to work out with the PM and the team is a smaller Requirements Management plan for:

Traceability of the requirements
Requirements Communication
Requirement Deliverables / Requirement Package

5. The current state documentation or the business workflows are not always made available.

This could be a show-stopper if you are a BA on a Business Process Re-Engineering Project. The current state versus to-be state business workflows are essential to that type of project.

What if you are on a project to implement a new system at a client organization? In this case, it becomes more important to draft future state business workflows and or business use cases during your elicitation period. Project estimations often do not account for time spent focusing on current state processes on an implementation project as this is an assumed responsibility of the client. You can reiterate the importance of utilizing current procedural documents to ensure that nothing was missed when defining future-state documentation.

6. Business requirements have received sign-off however the requirements continue to change during the implementation phase.

Not every change request to the base-lined requirements ‘need’ to be accommodated. Most changes need to go through a change control process which means they can be addressed at executive review meetings to identify the potential impact to the project go-live dates or success of the project.

BAs need to use a model for assessing the risk and be ready to answer risk score and drivers behind the new business requirements.

7. Stakeholders are not prepared for the elicitation session(s).

Stop the elicitation session by taking a break and have a sidebar conversation with the client’s Lead BA and PM. You should take a quick pulse check and get agreement on how to change gears.

While it may be a disappointment that that single elicitation session was not successful. It would be far worse to continue so it’s better to spend time planning the sessions, prepping the attendees and marking out the information that is required to be brought to the meeting versus continuing on and getting only some of the information.

Lastly, remember that most implementation projects do not have the budget to continue iterative rounds of elicitation sessions. This can be the main reason for overages in requirements projects. You must avoid this situation and assist with mitigating it if it occurs.

8. All product enhancement requests are ranked as “HIGH”.

If you are on a project installing or implementing software, your focus is on what the client needs now for their business to go-live with the software they are implementing.

At times, the perceived needs by the clients are more of ‘wants’ versus ‘needs’. If this is the case, you might be able to negotiate with the clients by holding a prioritization meeting and using certain criteria which helps they categorize those into Critical, High, Medium and Low.

If that fails, utilize relative ranking 1 thru n. Make a recommendation for the cut-off for the Critical and High items as well as the Medium and Low.

9. You cannot obtain the buy-in to conduct formal Stakeholder Analysis.

If the client has been a long standing customer, they expect that their partnered IT solution company understand who they are and what they do. They often become agitated if you start over and ask about their vendors or their stakeholders.

Stakeholder analysis helps to ensure you have not missed the evaluation of certain needs. When you need to be a little covert about validating or identifying the stakeholders of the project; do so by validating the stakeholders in each elicitation session or when addressing a new business segment area. You can continue to capture the information regarding the stakeholders along the way and include it as a reference in the final requirements package for client review.

10. Resources responsible for elicitation are not communicating requirements.

During projects that hold parallel paths of elicitation, it is not always feasible for the Lead Business Analyst to be in all of the sessions. In this case, it is typical that there have been assigned Responsible and Accountable resources for each area of elicitation. The Lead Analyst needs to share with them the expectations of how to communication requirements to him/her and share their requirements. Request the documentation and give the deadline for the information.

If resources continue to not provide their information, the Business Analyst needs to communicate the expectation of the documented requirements by a stated date and copy their resource managers along with the Project Manager. Not obtaining the necessary team requirements internally can jeopardize the requirements documentation and should be escalated as a project risk if it continues to be an issue during the project.

Requirements Risk often become Project Risks as such they need to be communicated with the Project Manager and worked into the Project Governance. The risks can be mitigated if managed early and BAs often see these risks first. BAs can contribute to mitigating project and requirement risks. Learning how to identify these risks and recognizing how to handle the situations is important to managing those risks.

Don’t forget to leave your comments below.

Maryanne Miller, CBAP, Business Services for MEDecision, Inc., has over 15+ years of business and technical experience in the corporate world of healthcare IT services. As a professional consultant providing business and technology leadership; her areas of experience include business process improvement, business analysis, and Healthcare IT. For more information see: http://www.medecision.com/

Managing Risk the Tour de France Way

Written by Paul Mulvey on April 27, 2010. Posted in Articles.

It’s the third mountain stage in the Tour de France (TdF). A few riders are in the lead as they wind their way up a mountain. The number of riders in the lead group starts dwindling – 12, 10, then 8. All of a sudden, around a hairpin bend, Jan Ullrich weaves across the road accelerating, pulling away from the pack. What will Lance Armstrong do? Chances are good that the US Postal team has thought about this risk and planned for it. This means that Armstrong will know exactly what to when Ullrich pulls this move, and the team has responded to many other risks up to this point to get Armstrong in the lead group.

Before I “race” into what Armstrong does and how the TdF teams manage risk, I figure that I should discuss risk analysis. Risk Analysis is technique 9.24 in the BABOK v2.0 that you should become familiar with. If you’re not familiar with risk analysis, this is the article for you.

A risk is an uncertain event or occurrence that can have a negative or positive effect on the project team’s ability to achieve an objective.

How do you plan for uncertain events? Through creation of a risk management plan!

The risk management plan includes a list of the possible risks that you may face during the project. You should create this at the beginning of the project, and update it as the project progresses. Each risk should include a description of the risk, the likelihood that a particular risk will occur and its impact, and how the team is going to respond to the risk should the risk become reality. Now because risks are really uncertain events, and uncertainty is just, well, uncertain, you can’t possibly plan for every risk so concentrate on those that are more likely. For instance, if one of your stakeholders suggests that you hold your requirements workshops in the building’s new outdoor garden courtyard, a reasonable risk would be that it might rain forcing cancelation of the workshop; while pieces of Skylab falling out of the sky would not.

Another thing that you need to include in the plan is your team’s Risk Tolerance. This is how much risk can be tolerated, and it may be different at different points in the project. Tolerance levels are: Risk Averse – will seek to reduce negative risks and accepts reduction in potential benefits in return for a more certain outcome; Risk Neutral – the benefit of the risk response must outweigh the “costs”; and Risk Seeking – willing to accept high risks in order to maximize chances of success.

Let’s look at the relationship between probability and impact. Suppose that we come up with a risk that it might rain on the day of our requirements workshop. The probability would be the chance that it would rain. The impact could be high or low depending on the availability of a tent or shelter. Our response could be different depending on how we plan to respond. For instance, we might avoid (hire a company to erect tents in the courtyard), accept (oh, well, we’ll just get wet), or mitigate (negotiate with the stakeholder to host the meeting in the company boardroom instead to lessen the chance of the impact). How do you determine probability? Look at the weather report, or if it’s too far into the future, look at the region. If you’re in Seattle, rain probability is High – Arizona? Low.

At this point, you have a list of events that may occur such as the table below.

Risk	Probability	Impact	Trigger	Response
It may rain during the outdoor workshop	High	Low	Begins raining	Avoid – we will erect tents in the courtyard garden large enough to house all meeting participants

So how does all this risk management work in the Tour de France?

The TdF is a grueling 2,000 mile + stage race, with twenty teams and 10 riders per team. It takes place over three weeks in July, and the winner is the one with the lowest overall time across multiple individual day races (called stages). Very simple objective – tough to get there.

Each team has examined its own strengths and weaknesses, so they have their own way of approaching the risks that present themselves in the race (you have performed a SWOT analysis, haven’t you?). Let’s look at one team’s stage one risk management plan. No one has started racing yet, so there is no leader. It’s a flat stage so there will be a mass sprint at the end. Your team does not have a great sprinter (your team’s weakness), so you probably are going to consider yourself risk-averse at this point. You don’t want your riders to risk getting caught up in a big crash at the end, ruining those cyclists on your team that are really good in the mountain stages (your strength). So, let’s create a risk. The risk is that your team will likely not win this stage. The probability that this will happen is high because you don’t have a strong sprinter. The impact is low because in this stage, riders will only be seconds apart instead of minutes or hours, and that time will be easily gained in the mountain stages. Your strategy is then to accept the risk. There is no real effort to try and win this stage because you are going to win in the mountains with your climbers.

So, now we’re into week two of the TdF and in the mountains. Armstrong is in first place overall, but there are some challengers who are within striking distance and could challenge him for the yellow jersey (what the overall leader wears in the race). Lance also put in a very fast climb yesterday so he has a two-minute advantage over second place. Will we be risk averse or seek risks in today’s race? Generally, the strategy would probably be neutral – protect the yellow jersey and only attack if the opportunity presented itself. Let’s list some of the risks that may be on this day’s risk management plan.

Risk	Probability	Impact	Trigger	Response
Jan Ullrich attacks	High	High	Ullrich accelerates on a climb	Mitigate – Armstrong will hang on Ullrich’s wheel, making Ullrich do the work but will not let Ullrich gain time.
Stephane Heulot attacks on the mountain stage	High	Low	Heulot accelerates or breaks away on a climb	Accept – Heulot is 45 minutes behind Armstrong in overall time and will not be able to gain that much time on the climb. Armstrong will not win the stage, but will not lose the overall classification. Armstrong will let Heulot get away.
Richard Virenque attacks	High	Medium	Virenque attacks on a climb	Exploit – Virenque is an excellent climber, and if Armstrong can force Virenque into the attacking position, Armstrong can ride on his wheel, making him do more of the work while Armstrong still retains the lead in the overall classification.

These are just some of the risks that the race team managers and the riders face every day. They plan for some of these uncertain events and react based on the response that they have planned out. How can you use the lessons from the TdF on your projects?

Follow these three steps:

Think about what uncertain events might arise within your project. Write them down. These are your risks. For instance, one stakeholder would like to hold the requirements workshops in the company’s new garden courtyard. A risk may be that it might rain during those sessions.
For each one of those uncertain events (risks), determine what the likelihood is that each one will materialize and then the impact of that. In Seattle, WA, raining on outdoor events is a higher priority than it is in Phoenix, AZ.
Determine what will trigger the realization of the risk (how you know that it’s happening), and how you will respond when it occurs. This is your risk response. For instance, if the rain starts, that will trigger your risk response. You then know exactly how your team is going to respond because you have thought it out ahead of time.

Remember, BAs should perform risk analysis because not everything will go as planned. By developing appropriate responses, you are effectively planning for some of those situations that may not go as you expected. You will be able to keep the project moving in order to accomplish your objectives and not stumble or stall because the team doesn’t know what to do.

So what did Armstrong do when Ullrich attacked? Armstrong accelerated right along with him. He knew the risk that Ullrich posed, but instead of thinking about his response, it was calculated and thought out that morning with the team director. But don’t worry about Armstrong coming into your company and taking over your job as a BA just yet – he’s training for this year’s TdF showdown with Alberto Contador.

Don’t forget to leave your comments below

Paul Mulvey, CBAP, is a Lead Business Systems Analyst at UPS. He currently rides a Merlin road bike and runs a 53/39 up front and an 11-21 in the back, although with that ratio, the climbs seem to get harder each year. He can be reached at [email protected].

Bad-Ass BA Lessons. Part 2

Written by Rebecca Burgess on July 14, 2009. Posted in Articles. 1 Comment on Bad-Ass BA Lessons. Part 2

Co-Authored by Cecilie Hoffman

This article is a continuation of the 10 Steps to Becoming a Bad Ass Business Analyst. These steps will help you take your professional capabilities beyond most people’s expectations and help you to stand out as a leader. In the first installment we covered:

Step 1. Exploit the hidden power in “menial” tasks
Step 2. Delegate!
Step 3. Compose in real time
Step 4. Define gonzo success criteria

Let’s move on to activities that establish you even more into a leadership role.

Step 5. Ask the Crazy-as-a-fox Stupid Questions

Slang: “crazy as a fox” – the fox is considered a cunning creature who may choose to act in a manner that appears to be foolish or stupid, but actually advances its underlying plans, or, in the case of fox hunting, outwits its pursuers and saves its life.

All business analyst job descriptions should have these four expected duties:

Asks the questions that no one else dares to ask, and that everyone wishes somebody would ask.

“I’m not sure I’m following, it sounds like we have made an assumption that magic happens at this point in the process, and all the customer record duplications are cleaned up and removed. Could you tell me again how this is going to happen?”

Asks the questions that, once answered, will bring everyone to the same level of understanding.

It may be the case that some people in a meeting know what a particular TLA (three letter acronym) means, but others have no clue, and are having a hard time following the conversation. The “stupid” question, “sorry to interrupt, but could you tell me again, what SRM stands for?” isn’t stupid, it is a kindness.

Crystallizes the issue for people to understand what the sticking points are.

You may need to go out on a limb and take the risk of oversimplifying, but it is a risk worth taking. For example, it is not unusual for two team members to be arguing vociferously when they are actually in violent agreement. It’s your job to remove their blinders and show them how their opinions can actually dovetail. Try paraphrasing their positions, and then suggest how they can be combined.

“Let me tell you what I’m hearing. Lakshmi, you feel that A is the most important issue. Jorge, you’ve been saying that B has to be addressed first. I don’t think this is a win-lose situation. Your recommendations are not mutually exclusive if we do C, which essentially combines A and B. As for D, can we forgo it? Doing so would remove the risks we are concerned about. What would the ramifications of that approach be?”

Ask the questions that lead to out-of-the-box thinking.

One interesting “stupid’ question involves asking for the anti-solution and using the resulting suggestions to generate discussion on how to resolve those problems.

“Let’s spend a few minutes thinking out-of-the-box with the anti-solution. If we really wanted to mess this situation up, what would we do? [much laughter and crazy suggestions which you capture as discussion points] And how can we avoid point A? What about point B – aren’t we actually making that worse with this requirement we just defined? Does this raise the possibility of an entirely new solution/policy/process?

Step 6. Get Their Attention

Slang: A “clue-by-four” is a broad hint, firmly delivered. Also a metaphor for enlightenment. This term derives from a western American folk saying about training a mule: “First, you got to hit him with a two-by-four. That’s to get his attention.” A two-by-four is a standardized size for boards used when building – roughly 2 inches thick by 4 inches wide by multiple feet long.

People, unfortunately, don’t always pay attention to potential risk. Risk as seen through our BA eyes frequently has to do with the consequences of missing information. This kind of risk can be overlooked or underestimated by people who usually focus on delivery risks. The clever BA needs to not only identify the risk, but also assess the severity of the risk, and frame and communicate the risk in a way that makes the consequences clear and unappetizing.

The fact that Risk Management is usually considered a project management activity does not preclude a BA from putting this methodology into her own toolkit:

Identify, characterize, and assess threats
Assess the vulnerability of critical assets to specific threats
Determine and quantify the risk severity and likelihood of occurrence
Identify ways to reduce or avoid those risks
Prioritize risk reduction measures based on a strategy

Capturing this information in a tool like the Failure Mode and Effects Analysis (FMEA) permits you to share it with the stakeholders and get their agreement on the existence of the risk and buy-in to the risk avoidance and diminution methods. Then, when the stakeholder isn’t paying attention to a promise or deliverable, you get the joy of saying, “Madam Stakeholder? I just wanted to gently remind you that three weeks ago you promised to provide me with headcount of your developer teams so that we can estimate the number of licenses that will need to be negotiated for this third party application. According to the agreed upon risk management plan, if we don’t have the information by tomorrow at 5 pm your local time, we will have to defer all the requirements from your organization until the next phase of the project.”

Risk Management is traditionally the responsibility of the project manager. However, identifying risk is an activity that falls squarely in the lap of the savvy business analyst. Take some time to become familiar with it and the tools to support it.

Step 7. Schmooze Those Stakeholders

Slang: “schmooze” means to chat in a friendly and persuasive manner, especially so as to gain favor, business, or connections. Derivation: “schmooze” came into the English language from the Yiddish language shmues, meaning talk.

Stakeholders have the power to help you or hurt you, and if you surprise them with something, they will almost always hurt you. Make sure that they know when something is happening in your project that will touch their sphere of influence and that they buy into the change.

When you identify your stakeholders, those with the most power to help or hurt your project are the High Priority stakeholders, and should be regularly schmoozed by you and/or one of your key team members. At a minimum, meet with them regularly to keep them apprised of the project’s progress and potential impacts on their area of influence. Make sure they know who is supposed to be representing their interests, and make sure you understand what those interests are. Ask them what their success criteria are for the project, and if their idea of success is not in line with the project’s goal, perform proactive change management. Build bridges and help them understand that you are looking out for them. You will undoubtedly have to deal with them again in the future.

Step 8. Rat Out Those Underachievers

Slang: to “rat out” is to inform on, or tattle.

You’ve presented your requirements gathering plan; you believe that there is a shared understanding of the strategic direction and everybody has signed up to do their share of the work. A couple of weeks go by and everyone has completed their commitments but one team, Team Slowpoke. You did everything to ensure that all the work would come in on time. You called them a couple of days before the deliverable was due and asked how they were doing. You got a non-committal answer and they said they didn’t need help. The day of deliverable came and went. You called the next day and said that you must have missed their email with the deliverable and would they resend it. By noon. Today, Thursday. Noon came and went. It’s Friday 10 am. The entire team meets at 8 o’clock Monday morning. What’s a bad ass BA to do?

You can talk to the laggards’ peers, expressing your concern, and encouraging them to put pressure on the laggards. In parallel, you can talk to your manager and express your concern. No whining, just concern.

“Mr. Manager, I just wanted to let you know that all the teams have provided the information that they agreed to provide, except for the Slowpoke team. They have said they don’t need help. They aren’t responding to email, or voicemail, and no one is in their office. I’m concerned about what we can accomplish in our Monday meeting given their lack of participation.”

Finally, in the 8 a.m. Monday meeting, you can review all the deliverables and their status, thanking all the other teams for delivering on time, and calling attention to Team Slowpoke’s failure to deliver. You can ask Team Slowpoke’s leader, in the nicest possible way, to explain why this failure occurred so the rest of the group can help resolve the problem. You remain silent, maintain eye contact, and listen. Then you can ask how they intend to resolve the problem and what the new due date will be. In fact, you might even offer to talk with their manager, in case this is a resourcing problem and the team needs to have something taken off their plate. Use your sense of judicious audacity here, to determine how far this needs to be pushed.

The worst thing you can do is do nothing.

This is the second installment in this three-part series. In the next installment we’ll talk about speaking truth to power and that all important BA accessory, the Facilitator’s Flak Jacket.

Installment 1	Step 1. Exploit the hidden power in “menial” tasks
	Step 2. Delegate!
	Step 3. Compose in real time
	Step 4. Define gonzo success criteria
Installment 2 BA Times July 14/09	Step 5. Ask the crazy-as-a-fox stupid questions
	Step 6. Get Their Attention
	Step 7. Schmooze those stakeholders
	Step 8. Rat out those underachievers
Installment 3 BA Times August 11/09	Step 9. Speak truth to power
Installment 3 BA Times August 11/09	Step 10. Put on your “Facilitator Flak Jacket

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’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 writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected]

The Language of Alignment

Written by Terry Longo on March 14, 2008. Posted in Articles.

Business benefit, growth, and profitability. Cost and risk. Value add. Forecast confidence. Customer satisfaction and loyalty. These are the measures of senior management. And if the goal of a commercial enterprise is to make money now and in the future, everyone in the enterprise needs to be behind that goal.

You manage a business unit and are looking at a red/amber/green dashboard report of your current programs, and you see that one is red. With your browser, you drill down the trail of red, each click bringing you to a lower level dashboard with more detail about a specific aspect of the at-risk program. Here is what you find:

The business’s success with a new product line is at risk because
The sales teams might not be prepared to sell the new product line because
Sales training for the new product line may be delayed because
Implementation of the Learning Management System (LMS) may be delayed because
The LMS module used for the management of training records may be delayed because
Development of the core code library for that module may be delayed because
The lead developer may need to leave the project due to an important and urgent personal matter

While the above may seem dreamy, it’s where we’re headed. Everybody in a value supply chain, from the lead developer to the LMS implementation project lead, to the sales team manager, to the business unit manager should, at any point in time, be able to express the status of his or her responsibilities in terms of Cost, Risk and Business Benefit.

The costs, risks, and benefits of what, you may ask? Simply put, for each person or team in the value supply chain, the costs, risks, and benefits of meeting their requirements.

Previously I have argued that the requirements management activities of planning, eliciting, etc. are necessary regardless of the domain in which one is working (instructional design, business strategy, database design, etc.). It is not only possible, but necessary, that requirements managers in those domains be able to express their status in terms of cost, risk, and business benefit. Rolling up requirements status to a senior level necessitates a common language, and that language is defined by the top-level requirement(s) of the enterprise.

We have much to do. In my next post, we will elaborate on the above and identify the top three challenges in achieving the dream.

Do you have any thoughts or questions about this post and earlier posts? Please don’t be shy! Let us know what you’re thinking by adding a comment below.

Terry Longo has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through http://www.hp.com/education/sections/pm_bus_analy.html

or at [email protected]