Below are three keys for increasing chances for sponsorship success in your organization:

1. Show small successes.  You’d probably like to see huge, sweeping change in this area, but let’s be realistic.  Our organizations and sponsor-level folks simply don’t have the bandwidth for that.  Our best bet may be to think small.  In fact, create an experiment that you can use to slowly, organically grow the idea of sponsorship in your organization.  

First, identify projects that suffered from lack of or poor sponsorship.  Without pointing fingers or blaming, be prepared to show where and how projects failed the organization due to an inadequate partnership between the PM and the sponsor.  Perhaps a key scope decision didn’t get made in an early project phase and resulted in subsequent scope creep, for example.

Then find a good partner to be the sponsor for the experimental project, someone who would be willing to try things differently next time.  Identify this person and make your case before your next project assignment.  If necessary, they may need to politic to get assigned as sponsor, so giving them advance notice will help.

Commit to partnering on your next project and be prepared to share the results with others in the organization.  Hopefully, the project will go better than the poor or unsponsored projects and you can use your results to inspire others. 

2. Make yours a sponsor-safe project.  Remember that sponsors are often ineffective in this role because they don’t really know what’s expected of them.  In his article, Avoiding the Accidental Project Sponsor, Ken Hanley points out the disconnect between our expectations of sponsors (they own them, right?) and the fact that they seldom get any training on how to be sponsors!  Would we hold anyone else to such high expectations and then assume they intrinsically know how to do what’s expected? 

Students often come out of my project management class with the feeling that their first task is to educate their sponsors.  And that’s great – as long as we make it safe.  Ask them to help you help them.  It requires professionally thick skin to own the fact that you need help from a subordinate in doing your job.  Remember:  If you haven’t had experience with good sponsorship, you don’t really know what to expect either, so learn together.

3. Be committed to making your sponsor look fabulous.  Take a page out of Vidal Sassoon’s book: “If they don’t look good, you don’t look good.”   If they look good, the project looks good and so will you.  Be intentional in thinking about how your actions and project results can reflect positively on them. 

Good project sponsorship in an organization is a win-win-win.  What works for the project works for the organization, the sponsor, and you.

Increasing Chances for Sponsorship Success 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

Fortunately, I have not been in a situation in which I wondered if I should do that. Unfortunately, I think this student had a specific situation in mind. It’s a tough question, especially if the person who is being difficult is a peer or more senior than you.

I can’t think of how you would ask someone to leave a meeting without making somewhat of a “scene,” and I don’t think it’s ever in anyone’s best interest to do that, including you. Of course, how to handle this kind of situation depends on many things such as the purpose of the session, how long it is, who else is in the meeting, how much time is left in the meeting, and other considerations. But I can think of some questions I would ask before suggesting how best to handle this.

First, have all reasonable steps for controlling the meeting been taken? Have the objective and desired outcomes been defined ahead of time and included in the invitation, for example? Have ground rules been defined, agreed upon, and posted? Has an agenda been provided that includes time for each topic and topic owners?

What other attempts been made to corral this difficult behavior? For example, have they been asked to hold their thoughts? Have their concerns or ideas been captured onto the “parking lot” so the meeting can continue as planned? Have techniques been used that provide an equal opportunity for everyone to participate, such as going around the table and soliciting comments or ideas from each person?

If the answer to these questions is yes, and it truly seems that this person is really out of control, the best answer may be to call for a 10-minute break. At a reasonable point in the session, simply announce that there is going to be a short break. Note the current time and write the time you will resume on the white board or somewhere so that everyone can see it. (Even if people aren’t expecting a break in this meeting, people will get up and take advantage of the time.)

Then, during the break, task 1 has to be stabilizing yourself. Many of us would be riled up in such a situation. I would likely feel frustrated, angry, embarrassed, or confused in such a situation, so I would need a couple of minutes to collect myself. If this is the case for you, let the offender know that you would like to talk with them in a minute or so, and then go to your desk, down the hall, or wherever you can go out of site. Take a few deep breaths and get yourself calm and collected.

Next, talk to the offender privately. Sincerely ask them if they are aware of how distracting their behavior is and if they are aware that they are derailing the objective of the meeting. It may honestly be that they are not aware of their behavior and its consequences. It never ceases to amaze me how many students share situations in which a difficult person was confronted about their “difficultness” and they had no idea. Sometimes making someone aware of their behavior is all that’s needed to change it.

Finally, I would solicit their help in finishing the rest of the session. Remind them of the objective of the session and help them see how they are a part of achieving that, which is why, of course, they were invited.

Easy? Absolutely not. And I wouldn’t suggest that it may even be politically wise to do this if the offender is a person way “above” you on the corporate ladder.

But controlling meetings takes courage, and it’s not easy. If it were, all meetings would run smoothly and be a good use of organizational resources. And I don’t hear from too many folks who feel that’s the case.

What has worked for you in similar situations?

What to do with Meeting Saboteurs? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

I was surprised at this reaction, which was expressed so emphatically. Perhaps she had no experience modeling requirements and felt insecure about her ability to do so. Perhaps she assumed that the norm for her organization was the norm for the industry. Perhaps she thought that models were truly technical in nature. Perhaps the line in the sand between business analysis and design was clear in her mind and modeling of requirements went into the technical bucket. Perhaps she thought that “solution” requirements (functional and non-functional) had no place in business analysis.

Is the real answer the consultant’s mantra “it depends?” In this instance I’m not convinced that it is. It seems to me that business analysis has to be concerned with what affects the business. If we’re creating a new web page or modifying one, we want to be sure that the navigation makes business sense (process modeling), that the information on the page is flexible and correct (data modeling), that how our customers interact with the website works for them (use case modeling). And I know that when we show people pictures, we uncover requirements that they would never have thought of.

Do these models have to be completed by a BA? No, they don’t. They can be performed by anyone in the organization who has knowledge of and experience in creating these documents. Having just said that anyone can model requirements, however, I’m now going to go out on a limb and make the case that BAs are best suited to model them. Here’s why:

1. Modeling is a great way to uncover expectations—those unarticulated requirements that are rarely revealed at the beginning of business analysis, if at all. One of the advantages of modeling is that it provides a structure that encourages questions.  Business analysts are in the best position to understand this structure and ask questions of the business SMEs. They also are in the best position to interpret the answers and understand the impacts of responses they receive.  Also, BAs generally recognize the importance of asking a variety of questions from multiple perspectives. Creating different models , such as business process, data, use case, low-tech prototypes, provides different viewpoints (more about which in a future blog).
2.  Being consultants and liaisons, BAs are in a unique position to understand the business and to translate the requirements into something the designers can design and the builders can build. They can also translate the technical design back into something the business clients can understand and approve.
3. BAs who can model requirements will almost certainly see gaps that jump out at them, screaming to be addressed. BAs, it seems to me, are uniquely qualified to address these gaps in a way that serves the business and makes sense technically.
4. BAs are probably more likely than technical staff to go to the business to get questions answered. At the risk of gross generalizations, technical people may have a tendency to answer the questions themselves, without getting input from those who will be most affected—the business users.

My advice is to recognize that business modeling is best done during the business analysis phase(s) of a project and is best done by those who understand their importance in eliciting requirements.

For Additional Learning:

Check out two of our modeling courses: 
Data Modeling Course
Use Case Modeling Course

View our article: Oh No, You Gave Me What I Asked For (pdf) (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.)

Should Business Analysts Model Requirements? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Of course, you don’t have to cross an ocean to experience cultural differences.  Cultural differences here in the US can even breed culture clash.

I was reading about someone from the Deep South who was communicating with a team member in the northeast part of the country.  The northern team member was offended that the southerner had called her “Ma’am.”  The southerner was completely flabbergasted that this could be considered an offense. 

This resonated strongly with me.  Intrigued, I polled the women in a class I was teaching regarding their thoughts of being called “Ma’am.” 

Two of us remember the first time we were addressed as such, and it was not a fond memory.

One woman was too young, by northern standards, to have been called “Ma’am,” and she was not looking forward to hearing it.

One woman’s response:  ”Don’t you ‘Ma’am’ me!” 

It reminded me of when I was teaching in a southern city.  The discussion came up regarding kids addressing parents as “Ma’am” and “Sir,” a common courtesy and show of respect in much of the country. 

In other parts of the country, it makes us feel old.  Here in Minnesota, it offends our sense of egalitarianism, and would even sound patronizing to many of us  (Don’t you “Ma’am” me!).  Many of us would cringe at being called “Ma’am” or “Sir” by our kids. 

Of course, like any generalization, these don’t hold true for everyone.  But they are interesting in terms of how strongly communications is impacted by culture and how important it is to not take for granted that because our passports look the same we necessarily communicate the same.

Mitigating the problems caused by regional cultural differences within one’s own country requires many of the same things as when working with people on the other side of the planet:

Be Open
Acknowledge differences and and share observations about those differences.  Make it safe.

 Get to Know Each Other
It’s a lot harder to be offended by someone when you know them than when you don’t.  Make time in virtual meetings to get to know each other.  Engage in “electronic courtship,” and start meetings with “small” talk.  That small talk helps mitigate problems in a big way.

I’d love to hear about your experience with regional cultures here in the US and their impact on your projects.

Culture and Communications was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

 

While this complaint pointed out some organizational issues, it also got me thinking about the role of the Project Manager (PM) and the Business Analyst (BA) in the early stages of a project. The two bodies of knowledge, the BABOK® Guide 2.0 and PMBOK® Guide – Fourth Edition each allude to work being done at the beginning of the project, so it is not surprising that conflict between these two roles can arise.

It’s easy for me to say that spelling out roles and responsibilities helps avoid this conflict. Using a responsibility assignment matrix, such as a RACI, is helpful, but it may not be enough. Looking back it seems to me that as both a BA and a PM, I never spent a lot of time dwelling on this issue. When I was a BA I didn’t have a project manager, so in a sense I was able to avoid conflict. When I became a PM, I was extremely fortunate to work with strong BAs who took initiative to define their own roles. Below I have listed what worked for us and why.

We worked on a project which had both business and technical complexity. We were introducing many new business processes as well as new technology. The project affected many business units within the organization, and the risk was high. Below are a few of the factors that I believe contributed to a smooth relationship between the BA and me (PM), and ultimately to a very successful project:

·         We each worked with our strengths. As PM mine was focusing on delivering the product (new software) when we had promised it, within the approved budget, and with frequent communication with the sponsor. As a BA hers was an incredible ability to understand the real business need—why the project was being undertaken, what was happening currently, and what we needed to recommend to the sponsor, which was different from what the sponsor had requested. Without her, I would have accepted the solution originally requested by the sponsor, a solution which would not have solved their business problem.

·         We kept the good of the organization in front of us at all times. There simply was no grab for territory, because it wasn’t about us. It was about delivering a product that worked–on time and within budget. One of the team members observed that she felt like we were giving birth. The good news was, though, that we didn’t have to suffer through teenage years!

·         I was focused on the date and budget, so all my instincts and training said to do the project quickly rather than correctly. Fortunately I had the good sense to listen to the BA and slow down when I needed to, which was usually at her insistence. Was this easy for me? Not at all! Am I glad I did? You bet!

I completely trusted the BA. But the whole topic trust is the topic for different blog on another day.

Four Tips for Avoiding Conflict Between the PM and BA was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Thought given to key elements of the meeting ahead of time can make for a more effective meeting.  Communication of those things insures that everyone arrives at the meeting with a shared understanding of why they are there and what they need to accomplish.

It’s fairly common practice, for example, to include an agenda in a meeting invitation. Topics to be covered and time allotted for each topic help to set expectations and keep people on track during the meeting.   Try adding two other things to your meeting invitations to take your meeting preparedness to the next level.

Specifically, when sending an invitation to a meeting in Outlook or whatever tool you use, specify two things:

Meeting Objective
Why are you asking for these people’s time?  What is the purpose of this get together?  Is it to brainstorm ideas for the new marketing campaign?  Prioritize software requirements for the new accounting application?  Resolve a conflict regarding the new patient intake process?  Make it absolutely clear as to what it is that needs to be achieved during the session. 

Desired Outcome
What is the desired outcome of the meeting?  What do the attendees need to walk out with at the end of the meeting?  Is it a list of ideas for the new marketing campaign?  Is it a list of prioritized requirements for the new accounting application?  Is it a workflow diagram for the new patient intake process along with signatures for approval from all attendees?  Whatever it is, be as specific as possible.

This is not particularly fun to do when you are the one sending the invitation.  It’s a pain to have to think specifically about the objective and what you need out of a meeting.  It’s a lot easier to just invite people who seem like logical attendees and then flush out the details later. 

But this practice forces the sender to give thought to whose names go in that To: box.  And that’s a beautiful thing when you’re on the receiving end!  

And, importantly, ending meetings is a lot easier and cleaner because we know when we’re done since we’ve named what it is we need! 

I’d love to hear about your meeting experiences and what approaches work for you.

2 Ingredients To Spice Up Meeting Effectiveness 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

1)      Test your technology. If you have never used the software or hardware for your virtual meetings, make sure you practice with a small group first. If you are doing a formal presentation, I suggest you reboot your PC right before you make it. We recently did a product demo where the presenter’s PC froze up right at the start. It took some fancy “tap dancing” to recover and keep the meeting going. Better to reboot first than to recover later.

2)      Presenters: clear your desktop. There is nothing worse than seeing an incoming email notice popping up on the moderator’s screen, or seeing his or her calendar reminder saying “Pick up Amie from soccer practice.” If you are a participant and there’s a chance your screen will be displayed during the session, this applies to you, too.

3)      Participants: minimize your distractions. Don’t text or read emails when you should be participating. Pretend it’s a live meeting. How would you behave? (I know, some of you out there would be on your Blackberries during a meeting. Ha ha.) One method to deal with this issue is to call on participants to ask for their input or thoughts. Some virtual meeting tools provide an “attention” meter. Ours does. It’s very useful to see who has other non-meeting screens in the foreground. It’s also good feedback for the facilitator on how engaging the meeting is going. That can be a bit deflating, I’ll admit, but an impetus to try harder!

4)      Larger meetings: use your name. I was recently in a virtual meeting with people I just met and every one of them sounded the same! I could not distinguish them and I kept asking “Jennifer is that you?” or “Was that Tom who said that?” In retrospect, I should have asked at the beginning for people to announce their name as they commented. Better yet, I think it should be a standard ground rule for virtual meetings.

5)      Take notes as you normally would. Unlike an in-person meeting, though, announce you are pausing to write down your notes. If people can’t see you, the audio pause is disconcerting and vocal people will fill it and try and move the discussion along. If you want to successfully capture an action item or decision, tell people you are writing and ask them to wait a moment. Make sure you write fast, though…virtual participants are more impatient it seems to me than in-person participants.

What other “musts” can you think of? I’d like to compile a top ten list and post it to our site.

Top Fundamentals for Successful Virtual Meetings was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

What makes tracking and reporting so difficult?  After all, “Where are you at?” is a completely reasonable and fair question.  In fact, without answers to that question, we have very little information for our stakeholders.
 
Many things make tracking and reporting on projects difficult. Project Managers often don’t have authority over the resources, and team members may not feel obligated to provide timely answers.  Those providing answers may not be clear on what information is being asked, or they may be dependent on others before they can report progress on their part of the project. Fear of the response to their answer also drives a lot of behavior around tracking and reporting.
 
Three things to keep in mind to make the Q and A around project tracking and reporting less painful:

1. Be transparent
Tell and show everyone how project information is being used.  Nothing feels like a bigger waste of time than  providing information for no apparent reason.  Make sure everyone understands what information will be needed and why – at the beginning of the project.  Don’t wait until the middle of the project when problems are encountered to start asking for information.  That will inevitably put people on the defensive.  Make it meaningful and get commitments on tracking and reporting at the beginning when the waters are calm.

2. Get input on mechanics
If you don’t already have guidelines or formats for reporting project performance, ask team members how they’d like to get needed information to you.  Email?  Voicemail?  Tick sheet outside your door?  What would be easiest for them?  Asking the team for input on the mechanics will help promote buy-in for the process.

3. Make it safe
Fear always compromises the timeliness, accuracy, and usefulness of reported project information.  If you think I am asking for an update from you so that I can hold it over your head in a performance review, what kind of an answer should I expect?  Rather than just asking “How are you doing?,” make it safe for team members to be honest by asking, “What obstacles are you encountering?”  If they can share that with you, they’ll be more likely to address their own issues and make the effort to get the work done when you need it.

See if trying these things doesn’t promote a more honest, timely, and useful answer next time you ask your team “Where are you at on the project?”  Your stakeholders are waiting for the answers.

Three Tips for Project Tracking Made Easy was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog