Before you get too far, I recommend taking a look at the blog from Rich and Elizabeth Larson (7 Trends…) on Business Analysis in 2012. Do your plans take into account these upcoming trends and predictions? Over the last 20 years I have found it extremely helpful to stay on top of trends, predictions, and the general goings on of your industry. The more you can stay in touch with them the better prepared you will be to address any given situation or need. However, have you been waiting for the New Year to make your resolution and plan? We talk predictions and address trends all year long and I recommend that you should make resolutions and plans that way too. Why?

Consider this; there were over 24 million references to New Year resolutions on various search engines this year. People coach all the time to start the New Year right with a “realistic” resolution. Whereas I like the idea of “realistic”, there are a few problems that can get in the way of making a New Year’s resolution successful. Timing, commitment, and lack of understanding about what you truly need. This is why I do not like New Year resolutions. Most resolutions are made without a basic understanding of these things.

We often make resolutions because we think we want something. It is so easy to get caught up with what society expects, influenced by friends and family and the next thing you know, you have a New Year’s Resolution to live up to. What we should be focused on is what we actually need. Sound familiar? All good Business Analysts know that we should elicit needs right? Not to mention, what we “need” is rarely found at the beginning of the year and does it really make sense to wait all year to make a resolution?

I suggest that we need to create resolutions when the need arises or becomes evident. When the need is actually known you can determine your level of commitment and plan appropriately. Hmm… now does anyone see a problem with the way most companies run their planning process? A lot like New Year’s resolutions! Then a BA gets assigned and they spend half the year trying to find out what the true need is… well I think you get my point. So my challenge to you is to take control of your resolutions and make them when they make sense whether in March, July, October or the New Year, if they really do happen then. Just make sure you understand your timing, commitment, and most importantly, what you truly need and then you can build a plan for success in 2012 and beyond!

A New Year’s Resolution? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

#5.  I wish for you a great plan.  Really?  A great plan?  What about turkey, candy canes, dreidels or snow?  Well we are talking Business Analysis here…. So, if you have been going at things status quo lately I urge you to stop and take stock of what is going on around you and analyze what you think is about to happen.  You must readjust your requirements plan for so many reasons during the Holidays taking into account schedules, preferences, culture and more.  I have already heard horror stories in just the last week of people scheduling meetings on actual Holidays, back-to-back meetings from 9 to 5 day over multiple days as well as people flat out declining meetings without explanation.  Now some of you may say how is that different than the rest of the year?  Sadly, it is not for some and all the more reason you need a good plan when you factor in the Holidays.  Business Analysts are leaders in their domain so it is up to you to step up and educate people on how it is done.

First, make sure that you are respectful of people’s time especially during the next 7 weeks.  Spread those meetings out.  Think through the types of meetings you have.  Can you combine some individual interviews into a panel or group interview?  Can you hold a JAR (Joint Application Requirements) workshop?  What can you do to ensure you can still meet goals and objectives during this abbreviated timeframe?  Ask your stakeholders what they think will work.  They may surprise you with some effective and creative options for combatting the Holiday hustle.

Make sure you know what everyone else’s plan looks like.  They may have similar ideas in mind or something completely opposite.  Some coordination here will go a long way in making the Holidays go smoother. 

Finally, factor in all of your personal time.  Do not let your Holidays be overrun by your job.  A personal plan that is working in conjunction with your work plan may make for your best Holiday season yet!

#4. I wish for you all the training that you need and want in 2012.  Well of course this ties into #5 of having a good plan.  It is neither too late to see if any budget has remained unused in 2011 or to plant the seeds with your management about building your skill sets for the next year. 

#3. I wish for you Verification and Validation.  So many companies around the world have big December releases and code freezes.  Hey… that means you have WAY less than seven weeks to get things done!  It is important to ask yourself a couple of questions: A. Are we building the right product?  B. Are we building the product right? 

In order to figure out if you are “building the right product” you must trace all of your requirements back to goals and objectives.  Yes, it is a good practice to do this early and often and perhaps you have already done so but another check at this time will help to both ensure the best interest of the business at heart and determine that all of your requirements are in scope.  Requirements that are not traceable to goals and objectives generally mean some kind of scope creep happened or you have incomplete goals and objectives.  Santa does not like scope creep.

In order to answer “are we building the product right” you must trace all of your requirements to design.  Did the design capture all of your requirements?  Did the designers alter any of your requirements without your knowledge?  Have you been attending those design meetings? 

In both cases, failure to answer these questions could mean that your 2012 might not get off to a great beginning because that is when your rework would start.  Happy New Year.  Whee.

#2. I wish for you lots of Holiday movies to enjoy and share.  I have about 65 in my collection (and counting) that I rotate through each year (I know, nuts right?).  What does that have to do with Business Analysis you ask?  Depends on how you look at it.  I would argue that there is a lot of Business Analysis going on in Charlie Brown’s Christmas.  Look at the analysis that went into choosing the Christmas tree, Snoopy’s Holiday decorations, the stakeholder analysis for casting the school play.  Need I say more?  Santa thinks not.  In the end these movies inspire me, motivate me and they instill in me a sense of joy and wonderment.  And everyone needs that.  Which is why…

#1. I wish for you what I would wish for myself – joy!  Joy in your jobs; joy in your pursuit of great Business Analysis, the joy of sharing with your families, friends and colleagues and whatever Holiday and reasons you have to celebrate.  And in this joy that we share, I do believe we can all find happiness, some success and peace.

Happy Holidays!

PS The Santa Claus of Business Analysis is making his list… checking it twice…

My B.A. Holiday Wish List for You was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Why do we do this to ourselves? 

Project managers know they should be getting input from the team on planning and the estimates for their work.  And they often do.  It’s what happens after that that’s problematic – namely, the input is ignored.

Why would we ignore the team, the people who know what it takes to get the work done?  Often because the answer they give is not what the customer or some other stakeholder wants to hear.

But who wins in this scenario?

The customer may think they do, but the team can only do so much, and if the project is late, the customer really isn’t getting what they want.

The project manager doesn’t win.  Their team is frustrated with them because any trust they might have had in the project manager is compromised as soon as they realize that the PM didn’t really want to know how long it would take.  In addition, the sponsor, customer, and other stakeholders lose confidence in the project manager because the deliverables are late.

The team surely doesn’t win.  And it only takes them until day 2 to realize that they’re going to lose!

If we ask someone a question, let’s ask because we really want to know the answer.  If we ask the team how long it’s going to take to get it done, let’s make sure we are willing to use the information we get, even if the answer isn’t what other stakeholders think they want to hear.

All stakeholders should have a reasonable chance of looking good past day 1.

On day 1, we look great. It’s day 2 that kills us! was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

As we drove around the site and watched workers putting the finishing touches on some of the walls alongside the highway, I asked Steve what it was that enabled him to manage this project so successfully.  He indicated that it was the use of Critical Path Method techniques that allowed him to manage the project as effectively as he did.  We visited the project room with project Gantt chart plastered all over the walls (we’re talking about a lot of Gantt charts), and he explained that by knowing what was on the critical path and understanding where and how much float there was, he was able to put his energy into more aggressively managing the right project components and focus less on those things that weren’t as urgent.  Those tasks on the critical path were non-negotiable.  Slack or float available on non-critical path tasks was made available to project team members on a first-come, first-serve basis.

I’ve been teaching CPM techniques as part of my project management classes for years, but typically when I get to that section of the class my students’ eyes glaze over.   This very concrete example (no pun intended) has reinvigorated my interest in presenting CPM and it has certainly helped me sustain the interest of my students while we do forward and backward passes, identify the critical path and calculate float.

I’m not sure what I expected to find at Mn/DOT in the way of project management.  Something bigger and better than what most of us work with, perhaps.   It was a pleasant surprise to find someone managing Mn/DOT’s largest project using regular PM tools used by regular PMs.

Critical Path Method – Valuable Techniques in Practice was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Round One

Relative sizing of user stories (Scrum)

• T-Shirt Sizes. For release planning we might use estimates of relative size. When less is known about the user stories for a release, we can estimate using a broad brush approach. Based on such criteria as how complex we think the user story is, how much effort it will take, and the unknowns or doubt, we give it a T-shirt size (XS, S, M, L, XL). We can then compare all the user stories and assign relative sizes. For example, we can take one user story and based on the above criteria assign it a T-shirt size of “Large.” We can then compare all the other stories against this “Large” size and assign the relative value of each story. This relative size estimating can help the Product Owner decide which user stories to prioritize for a release.
• Story points. We can then assign each T-shirt size story points based on an arbitrary scale, such as the Fibonacci number sequence (1,2,3,5,8,13,21…). If a user story is Medium, for example, we might assign 8 story points. If Large, 13. We can then translate the T-shirt size of all the user stories into story points. It’s important to remember that these story points are still relative. It really doesn’t matter if a Small is 2 or 3 points, as long as it’s consistently applied.

Waterfall relative sizing of projects, phases, deliverables, tasks.

For years we have used use relative size estimates on traditional projects. I have found this most effective when actuals have been collected over enough time to have confidence in the numbers. While I have only used relative sizing on projects and deliverables (such as a small, medium, or large report), I know of teams that have used them on phases and tasks as well. As with Scrum, we usually base traditional relative sizes on complexity, effort, and doubt (risk).

Round 1—Scrum wins, but it’s not a knock-out.

In my experience using relative sizes on traditional projects is often done to short-change the planning process. With Scrum the relative size of the user story actually gets refined as it approaches the sprint in which it gets delivered. While some traditional teams have the discipline to refine the estimates (as a project manager I always encouraged it), many more give in to management’s pushback about not changing the date, scope, or cost. Scrum processes, by their nature, encourage change and refinement; traditional processes do not.

Round Two

Scrum Planning Using Delphi (Planning Poker®)

 Planning Poker uses a kind of Delphi technique to reach consensus on the relative size of the user stories. Each person on the delivery team (not the Product Owner) is given a deck of cards, each card with a number. For example, if using the Fibonacci scale, the deck would have cards, each containing a number in the scale (1,2,3,5,8,13,21, etc.) going as high as desired. The Product Owner explains the details of the user story and at the count of three team members turn over the card with the points they think most appropriate. For example, two team members have turned over a 3, one a 5, two an eight, and one a 21. They discuss their reasons for “playing” their cards. Then at the count of three they turn over a card, the same or different from last time. Again, they explain their rationale. This process continues until consensus is reached.

Traditional projects using Delphi,

The Delphi technique involves a group of experts providing their estimates anonymously. Like Planning Poker, there are rounds. Although this can be done electronically, the experts usually write their estimates on a piece of paper.  A neutral party takes the estimates, shuffles them, and reveals them to everyone at the same time. No discussion is supposed to occur. For the next round and based on seeing the estimates of the others, each expert provides a written estimate which can be the same or different from the previous round. The process continues until consensus is reached.

On traditional projects I have tried using Delphi anonymously only once. It didn’t work. I have found the power of Delphi is in the discussion of each person’s assumptions about the estimates.

Round 2—Scrum wins, but again it’s not a knock-out. I love the Delphi technique. I love having the team reach consensus on estimates, whether traditionally or through Planning Poker. It provides team accountability for the estimate, and increases the chance of team and individual commitment rather than compliance. So what difference does it make whether traditional Delphi or planning poker is used? Everyone can understand Planning Poker. I have seen teams take to this technique immediately. But while Scrum makes things easy and practical, the traditional Delphi feels arcane. In addition, the traditional approach has some points taken off for having to use experts and for the required anonymity.

So, the current score is two zip. But the match is not over. Much more to come…

A Heavyweight Fight–Scrum vs. Waterfall: Estimating Part 1 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

I have always thought of business analysis as the most ambiguous and the most fun of the project phases. 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. As a business analyst I thought it was project management work. 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 four tips.

1. Break the effort into manageable pieces. We can estimate a whole lot better when our business analysis phase(s) are small. It’s easier to estimate a user story than an epic story, or one specific business process than business process modeling in general.
2. Choose your approach. We’ll estimate differently if we’re using a plan-driven approach (Waterfall) than if we’re estimating in a change-driven (Agile) environment.
3. Use a variety of estimating techniques. On many projects we cannot be precise about our estimates when we’re first asked how long business analysis will take. We usually 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 four hours to model a business process and we have five processes to model, it will take twenty hours to model business processes.
4. Brainstorm.  Talk 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. Identify all the deliverables/artifacts.  Make sure you know your deliverables before attempting to identify the tasks needed to produce them.  Here are a few examples of deliverables: user stories, agendas and minutes, “as-is” business process model, traceability matrix, to name a few.

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 communicate our status regularly, rather than surprising him after months of effort. What a lesson learned!

Five Tips for Estimating Requirements was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog