Skip to main content

Have You Dreamt about Being Your Own Boss?

Written by Cynthia Low on . Posted in Articles. 1 Comment on Have You Dreamt about Being Your Own Boss?

An interesting bit of information recently emerged from employment statistics in Canada (and one has to assume a global trend). The majority of new jobs created are in the ‘self employed’ category. This is right across the board, including business analysts, project managers and so many others in related fields. What this means is a large number of those who have been voluntarily or involuntarily displaced have become independent contractors and consultants, at least for the short term.

So, have you ever dreamt of being your own boss? Most of us probably have. We think about the flexibility and freedom it offers. We wonder how much more income we would retain if we simply contracted out our services. We imagine what it would be like to be our own boss. That picture of three-day weeks and extended vacations starts to look pretty compelling. But how realistic is it? And what are the downsides that need to be considered and managed to make you successful?

Keep the Coffers Full

One of the biggest challenges the self-employed face is developing a stream of regular income. Some transitions can be quite smooth. An example is Jeff, who left his employer to contract directly with a former client. He is getting paid to do the same work by the same people, minus the middleman. From his perspective this is a good move in the short term and will allow him to form his own consulting firm in the longer term. He could very well transition from being an employee to being an employer. The risk is that, as an independent contractor, he is easy to write out of a budget. If the project is cancelled, his contract is cancelled. My advice to Jeff would be to start looking for the next source of income now.

A contrasting example is Ruth, who has been working as an independent consultant for the past three years. Her business has been thriving – she was building up her client base and striving to meet needs in a growth economy. She is now finding that as her clients deal with cost constraints, their penny pinching is putting a pinch on her pocketbook. She finds herself in a position of having to learn and use a new skill set – business development. It takes time and endless energy to keep the pipeline of work flowing. My advice to her is, get business development busy and look for alternate channels of work to get her through this rough patch.

If you want to thrive in self-employment you need to be prepared to sell yourself every day. If you are someone who thrives on doing the work, but the thought of having to sell it doesn’t interest or motivate you (and may even terrify you), being self-employed may not be a viable option. When the economy is good it is often easy to pick up contracts based on an existing network. When the economy is in recession, a lot more people are fighting for more limited resources. You need to be up for the challenge.

Stay Focused

When you work for a company, others provide structure and direction. No matter how independent and initiating you are, it always helps to have deadlines looming. As Christine Keeling, a successful serial entrepreneur who runs Blueshoe Rewards, says “no one is kicking your butt to do things.” She has this advice for those starting out:

  • Build a plan.
  • Set priorities and stick to them.
  • Ruthlessly manage your time.
  • Get serious about managing your finances – remember you are tying your family’s livelihood to your good idea.

Develop a Support System

Just because you are working for yourself doesn’t mean you should be an island. Look for help and support everywhere. Christine points to the benefits of joining a support group for entrepreneurs, like Strategic Coach in Toronto. These groups often have speakers or resources to help you in areas that are new to you, whether it is building a business plan or marketing your services. You might want to find a mentor or even start your own networking group. My advice is to get all the support you can, wherever you can.

There is a lot of risk in going solo. There is also plenty of reward, as Christine points out. “When you are starting out, you are operating without a net. You have to like being on a roller coaster. But, at the end of the day, your successes are your own. And that’s the best feeling in the world.”

Dr. Rebecca Schalm, who has a Ph.D in Industrial/Organizational Psychology is Human Resources columnist with Troy Media Corporation and a practice leader with RHR International Company, a company that offers psychology related services for organizations worldwide.

FAT REQUIREMENTS; How to Lose Weight and Enjoy the Sunshine

Written by Keith Ellis on . Posted in Articles.

Have you noticed the obesity epidemic plaguing North America? Hey, I’m not talking about the kind you get when eating the wrong foods – I’m talking requirements obesity. Generating fat, hulking, documents that look terrible on the shelf gathering dust is not at all conducive to enjoying the summer fun. Here are a few ideas for slimming-down those requirements. Not only will you experience the joy of actually being ‘done’ and getting into the sunshine, people will better understand what the business wants, and projects get to be more successful. How cool is that as a win-win for everyone?

  1. Split requirements documents into three: scoping, business requirements, and detailed requirements. Most people don’t make this separation and end up spending way too much time detailing functionality that will never see the light of day, or in detail levels that are completely unnecessary for the task at hand. Remember – iterate.
  2. Separate the WHAT from the HOW. Get clear on WHAT the business wants to do before you start to detail HOW it is going to do it. Over and again, I find myself mired in a review of details that are not only clearly inappropriate, but inconsistent, because there was just too much about how some technical aspect of the system was going to be ____________ [fill in the latest technical jargon term]. Get people back to basics here and you’ll find both faster cycle times on projects, AND, vastly simplified requirements documents.
  3. Concentrate on just the right information. Business requirements fall directly out of understanding the desired state of the process flow, data flow, and business rules of the business. The actual ‘requirements’ are the structured statements describing the gap between current state and future state in these areas. Can we agree that this is Business Requirements? If so, why blather on about business case, or get into interface design, or have an opus on the history of compliance. It’s not really necessary. Sure, you need to have some additional pieces like a data dictionary if you hope to have everyone on the same page when you use the term “Customer”, but we’re not dealing with a lot of additional information.
  4. I’m willing to bet, in North America, more projects have managed to kill their intended benefits by failing to identify and manage interdependency than pepperonis have been killed to make pizzas. Business professionals need to have interdependency drawn out for them because this is the stuff where executives actually have to make decisions and love you for bringing it to their attention. Get into using context diagrams – every line on that diagram is an interdependency; or, at least have a section for this in your documentation
  5. Negotiate the details. Every project is different and needs different detail to bridge from business requirements to system design. It’s natural that a system selection/implementation will have fundamentally different dynamics than an off-shore design/build. In the face of high quality business requirements, the nuance of what detailed requirements should be for this project at this time can be negotiated amongst the project team. You’ll invariably end up with a tighter definition of what is needed, and better project momentum with recipients when you deliver what they’ve asked to receive.
  6. Remember – ALL YOUR STAKEHOLDERS ALSO WANT TO BE IN THE SUN TOO. Make the process efficient for everyone.

This is not about being lazy – this is about being hyper-efficient when it comes to projects. In candor, executives respect analysts that can make them, and their project team, more proactive and productive. Driven to extreme, you can wallow in requirements detail until the winter months start blowing frozen air over the corpse of your project. But, is this valuable – or can you get to the right information more efficiently; get better process around developing the information, and yield successful results faster? I’ll tell you – absolutely, yes, you can! Take a look at the base of www.iag.biz research – you can be iterative, reduce time to get requirements by 58%, AND STILL have documentation quality high enough to drive down change requests by 75%. So, what do you do with the 58% less time? Why, it’s summer. Go to the beach!

I bet every experienced analyst out there knows where to chop out fat without sacrificing requirements quality. I’d encourage you to share your stories of obese requirements – or fat-chopping solutions.

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

Bad-Ass BA Lessons. Part 2

Written by Rebecca Burgess on . 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:

  1. Identify, characterize, and assess threats
  2. Assess the vulnerability of critical assets to specific threats
  3. Determine and quantify the risk severity and likelihood of occurrence
  4. Identify ways to reduce or avoid those risks
  5. 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

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]

Show Your Value: Get Paid on Commission

Written by Kupe Kupersmith on . Posted in Articles.

Kupe’s Korner

I recently re-read an article on CIO.com, Should IT Workers Unionize. The author put forward the notion of IT workers unionizing.  There were many comments left by readers for and against the model. The idea of BAs unionizing is a concept that I found fascinating, but one that I totally disagree with.

This article reminded me of a conversation I had with a good friend, David Walker, with Borland.  He asked me if I thought business analysts would do anything different if their salaries were truly based on performance, A.K.A. commission based.  This is the complete opposite of unionizing. At the time I did not give him an answer, but now I believe we would absolutely change the way we approach projects, determine what techniques to use, and how spend our time every day. Projects are still failing or challenged at a high percentage.  As analysts we play a critical role in the success of projects.  If we really want to improve project success, let’s get paid on the success of our projects.  Are you feeling the wave of change? 

Let’s take a look at the sales profession for a moment. They sell products or services for a company and most of their salary is based on how well they perform against sales goals.  They miss their goal, their commission is less; they meet their goal they get their full commission, if they exceed their goal they get their full commission plus some.  So as a BA we play a key role on teams to implement projects or change for a company.  If your project fails your commission is less, if it is challenged you get most of your commission, if it is a success you get your full commission.  Man…I am getting excited just thinking about it. 

Ok, even if we don’t go the point of changing our salary structure we need to change our mindset and work like we are being paid on commission.

Here are a few characteristics of successful sales professionals that we can apply to our profession.  A successful sales person:

  • Ensures their goals are clear. Once they are set they work towards their goal every day.
  • Does what is necessary. Nothing more, nothing less.
  • Finds resources that can help them reach their goals.
  • Builds relationships to build credibility which leads to trust.

Goals: Before you start running down a path to elicit, analyze, and communicate requirements, make sure you, the project team, and business stakeholders are all on the same page regarding the scope and objectives of the project.  As the project is underway you should always look at the goals to make sure you are still headed down the right path.

Do what is necessary:  As an analyst there are many techniques at our disposal.  Just read the 300 plus page IIBA BABOK and you’ll see how many techniques we can use. Every project is different, so you need to do the work that will add value to your project.  Nothing more, nothing less.  For more information on this topic check out this webcast.

Find resources:  If you recall my last blog post, I talked about being the go-to person.  I said you need to be a consumer of information. There are so many resources (people, training classes, articles, discussion boards, etc.) available to you, and you need to find them and use them to be successful.  Here is a quote that I continually reference. 

“No one lives long enough to learn everything they need to learn starting from scratch. To be successful, we absolutely, positively have to find people who have already paid the price to learn the things that we need to learn to achieve our goals.”
-Brian Tracy, Author

In today’s environment we can’t go it alone.  Find the information and people you need to help you.  There is no shame in asking for help.

Build relationships:  Projects are all about people.  We work on projects with people and projects are created for people.  People want to work and help those they trust.  Take the time to really get to know the people you work with. 

Let’s not wait until we are paid on commission to change the way we work.  If we change our mindset now our project success rate will start to improve.  Things will be so good we’ll ask to be paid on commission!

Follow me on Twitter, http://twitter.com/Kupe

Estimating the Business Analysis Phase of a Project. Is it Even Possible?

Written by Elizabeth Larson on . Posted in Articles.

Years ago I worked on a large effort to reengineer a distribution center for a major retailer. We provided an estimate for both the business analysis work and for the entire project, which would involve the organization’s first use of Electronic Data Interchange (EDI), new business processes, many software changes, and the purchase of new barcode scanners. The business analysis effort took far longer than we anticipated, and at the end of it we refined our estimate for the total project. When we reported the new estimate to the president of the company, he literally pounded his fist on the table and asked, “How did we get to this point? Why didn’t we know sooner? You’ve already spent all this time on the project and what do we have to show for it? Nothing! Absolutely nothing!”

I have always thought of business analysis as the most ambiguous and the most fun of the project phases (by phase I mean phase, increment, or iteration). However, for many years it was my least favorite phase to estimate. I felt like I was guessing, simply pulling numbers out of the air. No wonder we were so far off.

Estimating the business analysis phase(s) is not easy. It is not hard, but it takes a willingness to think about exactly what work will be produced, and many business analysts do not have the patience. So for those of you who do not have the “stomach” to spend the required time to estimate business analysis, here are some tips.

  1. Break the effort into manageable pieces. We can estimate a whole lot better when our business analysis phase(s) are small.
  2. As we progressively elaborate our requirements, we can progressively elaborate our estimates. We go from Rough Order of Magnitude (ROM) to budgetary (deliverables identified) to definitive (requirements defined to a low level of detail).
  3. It is helpful to use a variety of estimating techniques. When we’re first asked how long business analysis will take, we really cannot be precise. We use analogous estimating, or experience with a previous project. If we have good history, we might be able to use parametric estimates. For example, if we know that it takes two hours to model a business process and we have five processes to model, it will take ten hours to model business processes. Providing detail on each of these techniques is beyond the scope of this blog, however.
  4. I have found it helpful to brainstorm with the people who are actually going to do the work. They usually have a more realistic idea of what needs to be done and how long it will take. I also like yellow sticky notes, since they can be easily added, taken away, and moved.
  5. But here’s the real key to estimating business analysis. Identify all the deliverables (work products, artifacts) you will produce during the business analysis effort. It is essential to first identify the approach you’re going to take, whether plan-or change-driven (Waterfall/Agile). It is also helpful to use the BABOK knowledge areas to identify which work products will be completed. During the course of an Elicitation event, for example, we might send out an agenda (one work product), update our traceability matrix (another deliverable), create an “as-is” process model (another deliverable), and update our list of issues (yet another deliverable). Next we think of the tasks needed to complete each work product, and finally how many hours the task will take.

Of course the real, real key is having the courage to communicate bad news. Which brings me back to the president pounding his fist. What I should have done was reported the plan vs. actual of the business analysis effort regularly, rather than surprising him after months of work.

What a lesson learned!

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]