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

BA as Product Owner. The role of the product owner is essentially that of the business subject matter expert (SME). Their main accountability on the project is to articulate the vision and define and prioritize product requirements. Their role, as the sponsor’s key delegate,  is to make business decisions. The BA has accountability to both the business and the project. On the one hand BAs need to ensure that end product or service meets the business objectives and that the  requirements are defined completely and correctly. However, they also need to ensure that the end product or service meets the project objectives and that it is delivered within the project constraints. Finally and maybe most importantly BAs are not decision-makers. They are facilitators, consultants, and hopefully trusted advisors.

BAs as Testers. Testing on Agile projects is an essential role. While theoretically the delivery team wears multiple hats, one of which would be that of tester, practically speaking I have seen more instances where outside testers fulfill this role. With the wide-spread use of automated testing tools on many agile projects, it is helpful  to pay attention to testing on its own with its own resource(s) devoted to it. It seems to me that as with any approach, separating both business analysis and testing from development work makes a great deal of sense.

BAs as BAs. So where do BAs most effectively fit into an agile project? As BAs doing just-in-time BA work.  Here are just a few ways the BA can support the agile project:

1. Help the sponsor and product owner define and articulate the business problem and product vision
2. Elicit requirements  using a variety of techniques, including facilitating cross-functional requirements workshops
3. Assist the product owner in developing user stories and the associated acceptance criteria so the delivery team will know when they’re done.  These criteria need to be more complete than, for example, “the order has been placed.” I have found that creating specific criteria tends to be difficult for product owners.
4. Trace user stories to business objectives and the product vision and throughout the sprint to ensure it’s actually been delivered as imagined.
5. Model the “as-is” and “to-be” business processes.
6. Model the expected system interactions, particularly when software is being developed.
7. Look for gaps in data requirements between what is in place and what is needed. Model the data requirements or work with the appropriate people to ensure that the data will support the new solution.
8. Create mock-ups of the new user interfaces.
9. Support the product owner by discussing business and technical impacts of and dependencies related to priority decisions.
10. Assess how ready the organization is to accept the change.

“Grooming” the backlog. So how can BAs do all the things BAs do so well without preventing the team from delivering an increment in short time frames, such as 2-4 weeks? By ensuring requirements are defined completely and correctly before each sprint begins. The BA can work with the product owner and other business and technical SMES as the delivery team completes each sprint. However, the BA is working on requirements for the upcoming sprint, rather than the current sprint.

While many organizations use the term “agile” to mean doing things in a quick and dirty way without adding a layer of business analysis bureaucracy, others have considered the consequences of omitting the role of the BA and are now recognizing the vital role BAs can play.

If you found this post interesting, you might also enjoy reading Avoiding Conflict Between the PM and BA, Part I and Avoiding Conflict Between the PM and BA, Part II. (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.)

Is the BA a Product Owner or Tester On Agile Projects? 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

UC Diagram-Training Example

Since most people refer to these as use cases, that’s the name I’ll use. They are a great way to elicit, analyze, and model interaction requirements. Plus, they help generate related requirements for interfaces, data, process, and business rules.

I gave a use case training class last week, so it’s fresh in my mind. It also influenced me to put this explanation in question and answer form.

Q. What is a use case?

Use cases and scenarios describe functionality that describes how actors interact with a system. The system could theoretically be anything, but use cases most commonly are used with online or web applications. The term “use case” is often a short version of “use case narrative” or “use case flow of events” and is shown as an oval in a use case diagram as in the example above. They are written as text and divided into primary, alternate, and exception scenarios.

Q. What is an actor?

Actors interact directly with a system, and can be humans, systems, or event/time triggers. In a banking system, an actor might be a teller who enters banking transactions and a Customer Information System that supplies and maintains customer data. They are shown outside the use case diagram as stick figures or using an icon like in the example above.

Q. What are associations?

These show which use cases an actor can initiate and which actors a use case can access. The line between an actor and its associated use cases depict the associations. The BABOK® uses the term association for this concept, and another common term for this is interface.

Q. What is a scenario?

A scenario is one path or flow through a use case. Typically a use case has a primary scenario, one or more alternate scenarios, and possibly exception scenarios. For example, a bank transaction might be completed using a customer’s account number (primary path), using the Customer Information system to look up the account number (alternate), or be cancelled (perhaps due to not locating the account number). One of my favorite ways to summarize use cases to my students is they are a collection of related scenarios in the accomplishment of a goal.

Q. What is a use case model and what are its components?

A use case model contains the use case diagram and the text scenarios and flows.

Q. What does the BABOK view as the specialized relationships in use cases?

There are two specialized use case relationships described in the BABOK. There is a third (and useful) relationship that the BABOK does not describe, but I listed it below for completeness.

1. Extend- documents the place in a use case to add future extended functionality, like an alternate path in a separate use case. “Search Name Phonetically” is an example below of an extend relationship.
2. Include – provides access to shared functionality in a separate use case. The common functionality is housed in a separate use case and is “included” by one or more use cases that share the same functionality. In the banking example, looking up customers by name is a common function that would likely be in an included use case, such as “Locate Customer” below.
3. Generalization –separates the general interaction steps from specific detailed steps for use cases that have a Parent-Child sub-type structure. In the following example, there is a generic Transaction entity with a use case of “Make Transaction” that has sub-use cases of “Make Deposit,” “Make Withdrawal,” and “Make Loan Payment.” Actors can be generalized as well. (This is an accepted and useful relationship that was included in BABOK® version 1.6. I would like to see it added back to BABOK® version 3.)

To sum up, Use Cases are an important and widely used technique for capturing interaction requirements. They provide a structured means to uncover many hidden and detailed requirements, and they can lead to related interface and data requirements. Because of their importance in the industry, expect to be tested on them in the CBAP exam.

LEARN MORE: For more information, read our article on Use Cases called Demystifying Use Case Modeling. It requires a simple one-time registration for you to access it. Once registered, you can read dozens of other interesting article on business analysis and project management. A good, basic book on Use Cases I recommend is called Applying Use Cases, Second Edition, by Geri Schneider and Jason Winters, ISBN 0-201-30891-5. We also teach a practical, concise training course on Use Case Modeling to learn this technique in-depth.

Scenarios and Use Cases – Useful Techniques 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

Finally, Mrs. Bear comes along and asks “If you had a mommy, what would she do?”  Choco explains that his mommy would give him hugs and kisses, sing and dance with him to cheer him up, etc.  When Mrs. Bear suggests that she could be his mommy, he happily goes home with Mrs. Bear and meets her other children, his new brothers and sisters: Ally (a baby alligator), Hippy (a baby hippo), and piggy (a baby piggy).  (Lemme tell ya – Hallmark commercials have nothing on this book when it comes to bringing me to tears.) 

For us adoptive parents, this is a favorite story because we define ourselves as parents not by our biological relationships and how much our children look like us, but by our emotional and personal relationships, how we treat each other and meet each others’ needs.  Love, not blood, makes us good mommies and daddies.

How many project managers feel like Choco, wandering corporate halls looking not for a mommy, but a sponsor, asking “Are you my sponsor?” 

What exactly are these PMs looking for?  What do their sponsors need to “look” like?  Who should their sponsor be?

 Too often, like Choco, we think sponsors need to “look” a certain way.  Unlike Choco, however, project managers are typically looking for someone who doesn’t look like them: sponsors need to be “higher” than they are. 

And that is quite true.  Whether it’s resolving cross-functional conflict, securing resources, or championing a project at all levels of the organization, a peer isn’t going to be able to help you with the things that you need from a sponsor. 

But sponsors don’t have to look a certain way.  They don’t have to have a particular title, work in a particular office, or have certain letters after their name to be effective sponsors.  Commitment and availability, not position, make us good sponsors.

I remember a student in one of my Project Management Fundamentals classes who suggested that her company’s CEO was the sponsor of all of her projects.  After all, she explained, that’s whose name was in the box labeled sponsor.  Now, this was at a Fortune 100 company and she was a novice project manager.  Upon hearing this, I thought to myself “I’ll bet you’re good, but I’ll bet you’re not that good.”  I’m fairly certain the CEO of that company did not have regularly-scheduled meetings with her to be updated on the project status.  In fact, I’ll even go out on a limb here and suggest that he probably didn’t even have a clue who she was.

So, unfortunately, that project manager didn’t have a sponsor; she had a name in a box.

Who makes for a good sponsor isn’t so much a function of what they “look” like, i.e., where they sit on the organization chart or whether or not they get invited to the executive 3-day offsite meetings.  It’s more about their ability to “do” what it is the project manager needs from them.   My last article, What’s on Your Sponsorship Short List?, highlighted some of the things project managers may need from sponsors.  The answer as to who will make the best sponsor must start there. 

For example, if capital acquisition isn’t a component of a project, a sponsor may not need to be someone with a say in budgetary expenditures.   Or, perhaps a project in which the project manager is relatively new to the organization and may need more assistance with navigating political terrain may benefit from a sponsor who is a little “closer to home” on the org chart.

Regardless of what is needed from the sponsor, there is one thing that every sponsor must be able to do for any project manager on any project: Be willing and available to develop a real, working relationship with the project manager.  Whoever management decides is the best person to sponsor a project, it must be someone who will actually make time on a regular basis to meet with the project manager and to consume information about the project in order to do what is needed from them.  A name in a box on a project management plan cover page does not a sponsor make.

In fact, I would rather have a “real” sponsor who is less senior but actually interested and engaged in the project and able to meet my needs, than have a senior executive who will never have time for me — even if it means that my sponsor may have to run some things up the chain of command for decisions periodically.  Those time delays are likely to be significantly less than the project inertia that results from an absent, disinterested sponsor.

So, sponsor assigners: When deciding who should sponsor organizational projects, don’t make Chocos out of your project managers!  Find out: What does Choco need and who is the Mrs. Bear who will be available and interested in making sure he gets that?

Because project managers of sponsorless projects wandering the halls may not be a sight that brings anyone to tears, but it is pitiful – and avoidable.

Next, Project Sponsorship – Strategies for Increasing Sponsorship Success.

Are You My Sponsor? 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