Well, like so many things in life it is simply not enough to just take Bob’s word on faith that it will be true (even though you know you want to lol). And to be honest, for many people the idea of being a Business Analyst and a leader sounds like a challenge to change not only what they do but who they are. So I have been on a quest to make this idea more relatable, palatable and just plain make sense. Why? Because I do not believe that you have to change who you are or even necessarily reinvent what you do to be a leader.

I went back to my training leadership roots and training from Covey and Carnegie which were instrumental to my personal growth. I searched my files for articles and presentations on leadership. All of it very good information. Foundational. Inspirational. But what I want to tap into is how it applies to real-life project application moments that Business Analysts live today, and that is a different flavor from the standard training and materials I grew up with. Additionally, how can I say it in a 600 word blog?

Finally, after resorting to the internet (shudder) like Moses parting the Red Sea, I found a definition that really resonated in me with what I have been trying to say (just better). And it was of course in the last place I looked – Wikipedia. Go figure. That global site that some of us find useful, some of us ridicule for inaccuracy and some of us revel in its ability to impart more information than we can possibly digest.

And here is what I found… “Leadership is stated as the process of social influence in which one person can enlist the aid and support of others in the accomplishment of a common task.”(*)

When you think about it, is that not the crux of what a BA needs to do? You enlist people to help you reach the requirements goals (what you have planned) for the project. You elicit – they give back. They inform – you analyze and translate. You document – they review. You baseline – they dramatically change scope but you react with aplomb and roll with the punches. You are leading through social influence in each of those areas (and more) while utilizing a set methodology. You don’t need to change what you do because you follow a methodology (and if you do not then we should talk). You simply try to do it the best you can. You do not need to change who you are because social influence is best done by being yourself. WYSIWYG please! Transparency really does go a long way for trust and credibility which makes people more open to your influence.

I am not trying to oversimplify what leadership is but I do like the formula of [methodology + transparency + social influence = leader] and therefore [BA + leader = success]! Yes, there will be societal, corporate culture and other unseen forces that could impact your ability to lead. All of which I would say are opportunities for your social influence. Business Analysts are leaders. They get people onboard with how they will contribute to business analysis and in turn, achieve extraordinary project results! What do you think? Let me know!

(*) Chemers, M. M. (2002) Meta-cognitive, social, and emotional intelligence of transformational leadership.

Business Analyst + Leadership = Success! was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Well, gentle blog followers … is there a more technical name for that?  Please contact me and let me know if there is (inquiring minds and all).  As I was saying gentle blog followers, if you have been following along, you now have a pretty good high-level definition of a Community of Practice and a Center of Practice.   A Center of Competency (or Competency Center) is about measuring and managing performance.  This generally includes: people, industry standards used, internal standards used and how competent people are in those standards.  Okay, on the surface that sounds easy, right?  Well, not when you are dealing directly with the human component.  People are naturally afraid of the measurement process and change in general even if it is helpful.  However, a Center of Competency (with the right model) done right will help to eliminate subjective measures, favoritism and other unwanted behaviors and practices that really do not help the success of our people or processes.

So, let’s look at a slightly deeper view of what a Center of Competency could entail.  It looks at the skills of the person who is performing a given task or technique.  It looks at the practitioner’s knowledgebase and tries to determine their proficiency in their discipline.  It looks at self assessments, overall maturity assessments (Business Analyst and Business Analysis).  It defines roles.  It looks at how to manage job expectations.   It looks at how managers and peers provide feedback (not criticism but honest to goodness, real and useful feedback).  It could include a mentoring and coaching program.  Which I need to point out there is a BIG difference between the two (sounds like a future blog coming your way on that topic).   My personal favorite is that it should tie one’s performance to pay appropriately.  It identifies training needs and it could include much more depending on the company culture and needs. 

Well I think you now get why this is not exactly easy.  Additionally, there is a large Human Resources component here which makes the challenge even more exciting!  The Competency Center with the appropriate model and approach will show people how to get from point A to point B – a clear path to keeping practitioners engaged in their careers.  It will help management understand the full spectrum level of support needed and also to reassure them of why they are making a good investment in their people and processes.  It could just be me, but I seem to think that this is just the right thing to do for people.  What do you think?

BACOE Blogisode #4: The BA Competency Center – Do you need one? OR… Competent is as Competent does. was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

This month, inspired by a debate on Agile vs. Waterfall, presented by the Phoenix chapter of IIBA, I want to compare Waterfall to Scrum in a variety of different ways. As I listened to the two sides during the debate, I was amazed at the number of the similarities, as well as the importance of the subtle differences. This month’s blog will explore both the similarities and differences. Before I begin, I want to stress the point that neither one is a methodology. Neither is prescriptive. Waterfall is an approach. Scrum is a framework, part of the myriad Agile methods. Both allow for the use of a variety of techniques. To be effective, both require an appropriate amount of rigor, although we acknowledge that both approaches have been implemented in a wide variety of ways. For the discussion below, we’ll assume the appropriate level of rigor for the project at hand.

Similarities

There are many ways in which these two approaches are similar. Both:

1. Have processes to request, approve  and  prioritize  changes. Both  put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
2. Stress the importance of communications.
3. Allow for more or less rigor as appropriate.
4. Find communications easier when the teams are collocated. 
5. Both face more challenges with virtual teams.
6. Have processes to manage the scope.
7. Estimate the work involved in business analysis whether phase (s), releases, iterations/sprints.

Differences

Many of the differences lie in how these processes are implanted. To understand the vast differences in implementation, we need to understand that many organizations have their own methodologies, so their processes for completing business analysis vary extensively. Also, many organizations use hybrids or “best of “breed” implementations. With that in mind, let’s examine some differences between Waterfall and Agile.

Intricate, large projects

On large, intricate projects with many business and technical interfaces and impacts, with a variety of cross-functional SMEs or with many compliance regulations, there are advantages to the Waterfall approach. While these projects can also be implemented using Scrum, it is harder when there are project dependencies.

• Coding and testing. On the large projects I managed, we were always touching programs and test data that other teams needed and vice versa. It seems to me that following a detailed  plan places less stress on all the teams. Even when slippage occurs or the team completes programs earlier than anticipated, following the plan and communicating variances in a more formal and proactive way is helpful to all the teams involved. Again, it can be done using Scrum of Scrums or other processes, but I have found that following a plan is a stress-reliever.
• Incorporating changes. Again, when there are approved changes and there are significant project dependencies, it can be helpful to change the plan, so that a schedule for completing these changes can be determined and communicated to everyone impacted by the change. This is particularly true when the approved changes have significant impacts and can cause changes not only to work completed by the team, but by work already completed and tested by other teams.

The winner: Waterfall!

Defining requirements when they are highly volatile

Waterfall projects have approval points, often called toll or stage gates. When requirements are unstable, business analysis can seem to take forever and the sponsor may get frustrated with what appears to be analysis paralysis. I once had a sponsor tell me that he had never seen analysis take so long, but  was surprised and delighted that the project get done so quickly once we had the requirements. Thoroughness in requirements definitely paid off. However, there was significant frustration as the churn was happening.

Scrum projects have the wherewithal to handle this kind of churn better in my opinion. User stories that are pretty well understood are closer to the top of the product backlog and are ready for inclusion in upcoming sprint(s) than “epics” that are less understood.

The winner: Scrum!

Managing scope and changes

On Waterfall projects schedule, cost, and scope baselines are established (as well as others). These become project constraints. When changes are approved and prioritized by the Business, the sponsor, often upon the recommendation of the project manager, needs to decide which of the baselines will change. I have talked to many Scrum proponents who argue that Agile projects expect change, but Waterfall projects do not. This assertion is simply not true. I have yet to be on or hear of a Waterfall project that did not expect changes. Having said that, modifying the schedule, particularly when it involves changing dependencies, can be cumbersome and frustrating.

I think managing scope on Scrum projects is easier in many respects, most of which relate to the fact that having small sprints helps the framework accommodate changes with far less pain. In addition, I have seen more consistency in the way changes are requested, approved, and prioritized on Scrum projects. 

The winner: Scrum!

I could go on with this comparison, but my little blog is turning into a full-fledged article, so I’ll simply list out areas where I think Waterfall wins and address them in more detail in future blogs.

Waterfall wins in these areas:

• Effectively using the role of the BA to define requirements completely using a variety of elicitation and modeling techniques. Although Scrum is catching up, it still lags behind.
• Defining the business need and business case. Most of the visioning I have seen on Scrum projects has tended to be superficial. Again, this may be due to the way I have seen it implemented.
• Getting from the “as-is” to the “to-be.” Ensuring that the solution in general and software in particular supports business processes or if not, that the business is ready for the change with such things as new processes, training, the required sales, marketing and support resources, etc.

Of course Scrum wins in some other areas, too…

Scrum vs. Waterfall: The Fight Continues was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

In our last blogisode, we got some insight into what a Community of Practice is trying to or hoping to accomplish. It is a fantastic start towards a COE and can really help to foster better relationships and maturity in your company. But while the Community of Practice is focused on best practices and good will, the Center of Practice is focused on standards and governance. Now before I go further, let me say that in the end it really does not matter what you call your area or how you choose to categorize it. The goal is maturity and the naming convention is strictly for the concepts we are discussing. “But Bob, doesn’t that fly in the face of having industry standards?” Kind of… and the reason for that is I am 100% dedicated to the idea that this is a cultural evaluation towards maturity. You pick and choose what you want and/or can bite off and how you want it to look. The experts may say Pluto does not meet the “standard” definition of a planet anymore but in my heart Pluto is still a planet, and I know what it is trying to accomplish out there all alone, on the perimeter of our galaxy. You go Pluto!

So if a Community is about best practices and a Center is about standards, what is the difference? Best practices are processes and artifacts that are widely used in the industry and known to increase the likelihood of success on projects when utilized appropriately. They are not enforced. Not all best practices are appropriate to use by a given company given their particular industry, complexity of projects and more. Standards on the other hand are processes and artifacts that are enforced and must be used. They have some form of governance either strict or can be albeit, light in nature.

A Center of Practice is a structure that brings together decision makers of Business Analysis from all over the organization or one governing body (team or person) to define the exact standards to be used by any practitioner of Business Analysis. Templates, processes, diagramming conventions, rules – anything Business Analysis related could be in play (more on this in future blogisodes). Now, I have seen Centers of Practice run by any number of titles including BA Managers, Sr. Directors, Sr. Business Analysts, and Managers of Practice. It depends on the goals for maturity and the overall level of effort and complexity. This could be a temporary assignment, a half-time position or a full time role with a supporting team. The Center of Practice owns the standard and enforces it either through their own structure and team or through an existing structure like a Project Control Office, Project Management Office (depending on how the company is structured). The Center of Practice will have many departments to collaborate with.

So the Community does not have to practice what it preaches until they become a Center. How many licks does it take to get from the Community to the Tootsie Roll Center of Excellence? One… two…. well, more than three I assure you! Again, our time is short but hopefully you are starting to see how your COE could be shaping up!

Next Blogisode: The BA Competency Center: Do you need one? OR… Competent is as Competent does.

Interested in learning more about building a Center of Excellence? Register for our free webinar on Tuesday, June 22nd at 1:00 p.m. CST.  Register

BACOE Blogisode #3: BACOP or BACOP? Community or Center OR… My Community won’t Practice what it preaches! was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

I’m giving a presentation at an upcoming conference called “BA Toolkit: Essential Tools for an Agile Project (or any other for that matter.)” I’m basing the presentation on a recent project that built our CBAP Online Study Exam. One of the tools I used on that project was the State Diagram. The BABOK® notes that these diagrams go by different names such as State Machine Diagram, State Transition Diagram, and Entity Life Cycle Diagram.

It proved helpful for a number of reasons:

1. A state diagram maps the official “states” or statuses that an entity can have, which is to say from initial creation to final disposal. It visually diagrams what would otherwise be a complicated verbal narrative or list. Whenever I map out one of these diagrams, it invariably leads me to find some more subtle states that I might have otherwise have missed.
2. It specifies a sequence of states or statuses that an entity goes through during its lifetime. If an entity changes states, there is always an event that triggers the change. The example below shows sample events (“Offer Made” and “Emp. Is Eligible”) as well as the process to respond to those events (“Accepts Job” and “Employee Retires,” respectively). The triggers and responses are often hidden requirements and the state diagram helps us uncover them. For example, the processes often become use cases and the triggers are an important pre-condition to them.
3. There may be specific things that should be performed when the entity reaches a new state. For instance, when a New Hire “Begins Work” in the example below, the process of “Intake New Employee” gets performed to manage the transition such as election of benefits and recording of personal details.
4. Each state might have its own unique data associated with it. For instance, a New Hire would have less data than an Employee who has started work. Retirees have even more attributes because of their retirement status. The discovery of new states will usually lead to uncovering additional data requirements. I love it when that happens!
5. Before an entity leaves one state for another, there may be some “clean up” activity to be performed. In the example, when transitioning out of the “Former Employee” state, the process of archiving the employee is done. For simplicity’s sake, our example doesn’t show what happens after that.

Here is an example state diagram. It shows 1) Five example states for a Human Resources application, 2) Transitions that reflect the business process in moving from state to state, 3) The event or trigger that causes a move to a new state, and 4) Activities that can take place upon entering or exiting a given state. 

Example State Diagram

To sum up, State Diagrams show the various states which an entity or class flows through during its lifetime (i.e., from creation to deletion). It also shows the events or triggers that prompt from one state to another, and formally labels the transitions. This type of analysis would normally be done only for complex entities that have multiple states or “life cycles.” They can help discover missing data attributes and processes involved in the various transitions.

You don’t need to be a proponent of UML or a specific methodology such as Object Oriented Analysis and Design to use these. They have value for most IT projects, and can help uncover missing requirements quickly. You might also get asked a question on the CBAP® exam, so add studying it to your preparation!

For more information, check out Wikipedia’s page on state diagrams. Make sure to scroll past the obscure entries like the “Directed graph“ and “Mealy machine.” We also cover state diagrams in our Business Process Modeling class and Data Modeling class.

State Diagrams: They Don’t Just State the Obvious was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

If an organization really wants their projects to succeed, and if you’re not convinced of that you’re really in trouble, then why is good sponsorship so elusive? As a project manager, is there anything you can do to improve the chances of a real partnership with a sponsor? That partnership is, after all, one of the top indicators of project success.

In this blog I’d like to suggest that we define what we should reasonably expect from a sponsor. In my next post, I will look at who is the “right” person to sponsor a project. Then I’ll suggest some things that PMs can do to improve their chances of sponsorship success.

So what should a PM expect from a sponsor? Actually, let me rephrase that: What should a PM reasonably expect from a sponsor given the project and the organization? The key word here is reasonable. If regular attendance at team meetings isn’t feasible, for example, then let’s not set anyone up for failure. PMs need to think about their Sponsorship Short List. What are the absolute must haves from this sponsor for this project? Your short list may differ depending not only on the organization, but also the sponsor and the project.

Some Sponsorship Short List options could include:

1. Articulate business and project vision
2. “Prepare” and distributes the Project Charter
3. Obtain funding
4. Define project benefits
5. Facilitate definition of requirements and acceptance criteria
6. Assist in acquiring resources
7. Approve deliverables
8. Make scope decisions
9. Resolve cross-functional and external conflicts
10. Champion the project
11. Provide guidance and direction as needed

Clearly, unless your sponsor is experienced and familiar with best practices, it’s probably not going to serve you well to present an 11-item list and announce that you need all of these things from them. Not only will they insist that they don’t have time (which is probably true), but it may be intimidating. If they’ve never done these things, how are they to know how to do them? No one wants to look incompetent, especially if you’re supposed to be the owner of the project.

So it’s up to you, project manager, to think about it and help them do their job.  Create your Sponsorship Short List: Pick three and define what, specifically, they mean.

If you determine that what you need most is a project champion, for example, what does that mean? What do they actually have to do?  Make a presentation at a meeting?  Include project update on senior management meeting agendas? Come in and cheerlead for the team once in awhile?  Write it down so you understand it. Use small, simple words so you know you understand. (No leveraging synergies!) Then, and only then, present it to them…and set them up for success. When they look good, chances are you will, too.

So if you are feeling like an unsponsored PM, give some thought as to what you’d really like from a sponsor and come up with your Sponsorship Short List.  Remember: Sponsors are sometime lousy at sponsoring because they don’t know what’s expected of them.  Help them understand, and make it palatable.  

It’s probably a learning opportunity for both of you.  If you aren’t used to sponsorship, then you will have to explore how to use them in whatever capacity you have suggested, as well.  Win-win.  It’s a beautiful thing. 

How do you get the best out of your sponsors? I’d love to hear your thoughts.

Next time, Are You My Sponsor?  Who in the organization is the best candidate for project sponsor.

What’s On Your Sponsorship Short List? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

So in my last blogisode I talked about the many paths to Business Analysis maturity and the need for you to first start with root cause analysis to determine why you think you need a BACOE.  Did you go through your Five Whys exercise?  If so, you may have found that your organization lacks standards, and the root cause for that might have been something like insufficient budget to document or the previous attempts at standardizing failed so we can’t do that again!  Or perhaps you have some standards and you found out that your organization lacks the ability to measure Business Analyst performance effectively.  That might have had a root cause like dispersed management in a matrixed environment.  Whatever the reasons, both make sense to move forward with a full blown BACOE model, right?  Well hold a minute!  This is why I say getting started is hard. 

There is a LOT to a BACOE and, although these are components of a BACOE, they are not all encompassing.  Calling yourself a BACOE may imply something that may not be what you need/want and/or misrepresenting your effort.  Trust me on this – I have learned the hard way!  Now, personally I love the concept of the BACOE, but it can be nuclear in proportion (which is why one must love the bomb if one wants a full BACOE).

The next step is to understand the different names/approaches and what they mean to your effort.  So what is in a name?  Let’s explore.  BA Community of Practice.  BA Center of Practice.  BA Competency Center.  BA Center of Excellence.  These are a few of the main concepts out there.  Really?  Really!!!  The approach and the name describes what your focus is and  is also a selling point when it comes to getting support from your management or community both now and later (more on that in future blogisodes).  So I want to briefly describe each approach so that you can have a better frame of reference for matching it up with your root cause analysis.

BA Community of Practice.  The Business Analysis Community of Practice is a structure that brings together practitioners of Business Analysis from all over the organization to discuss best practices, successes, opportunities for improvement, coaching, solicitation of ideas and other needs (like venting-which is healthy).  This is done regardless of methodology used or titles bestowed.  Just like the Girl Scouts – they are a community with a specific focus (oh Girl Scout cookies, why do you tempt me so!).   The Community is often run by a Business Analysis change advocate/champion in the organization or by a committee of peers with representation from multiple departments.  The Community of Practice generally has no authority to make changes to company policies, templates or processes.  It can be run in person, virtually, or both and may meet quarterly, monthly, or weekly depending on need and bandwidth.  It should be a safe environment where people are free to exchange information with the goal for improving overall quality.

It is already the end of another brush with danger and thrills – the BA Center of Practice definition is next!

Next Blogisode: BACOP or BACOP?  Community vs. Practice  OR…  My Community won’t Practice what it preaches!

BACOE Blogisode #2: Maturity is easy, it’s the getting started that’s hard! OR… How I learned to stop worrying about BA maturity and love the bomb! was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

The impetus for this blog comes from having just taught a successful training class in Data Modeling to a mixed group of BAs, BI specialists, technical architects, and business SMEs (subject matter experts). What made it successful was not only the learning that took place, but also the students’ willingness and eagerness to apply this technique back on their jobs.

I’ve been doing and teaching data modeling for as long as any business analysis technique. Many organizations I encounter think of data modeling as being technical and not BA work. Of course I feel differently, and have long viewed logical data modeling as business analyst work. The IIBA® agrees by including this technique in the BABOK.

Regardless of how you or your organization categorize Data Modeling (DM), you need to be prepared to answer questions on it for the CBAP exam. Here is a short over view of some Dm essentials:

• Data models capture the static data requirements of an organization for its ongoing business operations and decision support. It does that by defining and structuring entities, relationships between the entities, and adding detailed attributes into the entities. There is usually ancillary documentation you need to include that doesn’t fit strictly into the model. Two major styles of data models are entity-relationship diagrams (ERDs) and class diagrams.
• Concepts. Entities are the basic building block of a data model. The BABOK goes a little abstract on us by categorizing these as “concepts.” No one I know of except a textbook refers to entities or classes as concepts. The BABOK does it because an entity could also be represented by a class if you are using UML (Unified Modeling Language). In short, a concept is an entity or class depending on the DM style employed, and the term may appear on an exam question. I’ll use the term “concept” interchangeably with entity and class.
• Entities/Classes represent the people, places, things, processes, or events within the business. They have multiple instances that turn into rows in a relational database, and attributes, which become columns or fields in a database.
• Relationships are significant business connections or associations between “concepts” (there – I used the term). Relationships can be “one-to-one,” “one-to-many,” or “many-to-many.” The BOK uses the term “cardinality” to refer to the number of entity elements that are associated, namely one or many. Relationships may also be categorized by being optional or mandatory, such as “zero or one” or “at least one.”
• Attributes are the detailed facts about the “concept.” An ERD or class diagram typically lists the attribute name, relying on ancillary documentation for specifying domain ranges, the type of data an attribute can hold, and the definition of each attribute.

Here is an example data model, illustrating the terms above, and highlighting the four types of cardinality. Don’t be surprised on the CBAP exam if you are asked to interpret a diagram such as this. That type of question demonstrates the application of a technique, not just understanding the terminology.

Data Modeling is an important requirements analysis technique, and one you are likely to be tested on. Make sure you understand this technique for the exam, and then work at applying Data Modeling on the job. I plan to blog about that in the future – after I finish all the BABOK techniques!

Data Modeling – Why is that Technique in the BABOK? 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 attended an IIBA Professional Development Day in the Twin Cities recently, and a panelist mentioned what he thought was a cool, new concept. He was describing what an agile development team did on a successful project, and called what they did “high-tech anthropology.” My ears perked up when I heard the term, and thought they were onto something new and inventive.

Before starting development, the team in question decided it should go out to the field to watch subject matter experts (SMEs) actually doing their job. By observing workers in their work environment, the team discovered a major flaw in the assumption of the project sponsor about the proposed technology. They prevented the wasting of substantial project funds by doing observation. The consulting company doing the work dubbed this approach “high-tech anthropology.”

Well, not to be cranky…but, this is simply the packaging of a tried and true technique with a new name. The consultant’s “exciting new approach” was actually the long-standing technique we call observation. I hate it when someone tries to “invent” something new by renaming a standard method. OK, enough ranting. You can call me the “BA Curmudgeon” if you want.

Observation is a common elicitation technique that is used to watch people in their natural work environment. It’s useful to uncover requirements and as an adjunct to other elicitation methods. I first learned the value and power of this technique in my first job as an analyst back in the 1970s (I was in high school – just kidding). While analyzing the various departments in a bank for process improvements, we routinely observed each department in action. We’d follow personal bankers, tellers, mail room staff, etc. around their jobs. Heck, I was even a teller for a week – a scary thought, but actually doing the job of an SME gave me far better insights than just watching or talking to one. (If you want to get fancy, real anthropologists call doing an SME’s job “participant observation.”)

It is also valuable when stakeholders are unwilling or unable to articulate their work or their processes. A business analyst may need to do observation to conduct basic discovery work when more routine methods prove fruitless. For example, observing personal bankers opening new accounts on the job revealed some of the exceptions they face, but couldn’t articulate in an interview.

For the CBAP exam, it’s useful to know that the BABOK mentions two types:

• Passive / invisible – BA observes the SME doing job or following a process, but does not ask questions.
• Active / visible – BA observes the current process and takes notes, and may dialog with the worker (and even perform the process).

To summarize, observation gives us realistic and practical insight into business processes as they are actually performed. It can help elicit informal details and actual practices that may not be captured in more formal sessions. This method isn’t practical for new processes, or for those with lots of thought processes. It can be time-consuming and disruptive to “observes.” Like any technique, observation can’t uncover all needed exceptions and critical situations. But, with all its advantages, there’s a reason why this technique has stood the test of time. And, why people are tempted to repackage it as something new.

For Additional Learning:

Check out our CBAP Certification Prep Course.

To familiarize yourself with the actual CBAP Exam, try our CBAP Online Study Exam.

You may also find our our article: Foolproof Guide to Passing the CBAP (pdf) valuable. (You must be a Watermark Learning Member to access this article.  Membership is free and allows you to access valuable skill-development tools, such as articles, webinars, eNewsletters and special discounts.)

High-Tech Anthropology? A New-Fangled Name for a Tried and True Technique: Observation was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog