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

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

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

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

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

The close of one year tends to make one reflect on what has occurred in the past year and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

1. Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:

• Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.
• Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
• PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.

2. Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue.”

 In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

 3. PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.

 The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

 4. The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:

• Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
• Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
• In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.

5. BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:

• Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
• Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
• Post-project follow-up.We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.

 6. The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.

• Travel budgets.Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
• Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
• Collaboration toolshave made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.

 7.  “The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools.

7 Trends in Business Analysis and Project Management to Watch for in 2012 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Fortunately, we have a little meeting protocol where I work.  In our organization, you can’t schedule a meeting without identifying the objective of the meeting and the desired outcome.   At first, I didn’t think it would be difficult to get my thoughts around those things and document them.  (Did I mention I had a lot to talk about?)

But when it came to actually  spelling out the objective in the invitation, my fingers froze. I hadn’t really gotten much past “To talk about all the stuff I need to talk about.”  That, of course, left me with nothing to describe in the way of desired outcome. 

So I took my hands off the keyboard, put them on my forehead and started to think:  What is the purpose of this meeting?  Why should he take his time, that is, the organization’s most valuable resource, to meet with me?  What do I have to say that is worth his time to discuss?

The truth is, I did have a lot on my mind.  I was feeling overwhelmed and unfocused with more to deal with than I had bandwidth for.  I had ideas and thoughts about some things I was excited about and wanted to be able to address all of it, but I couldn’t.

The truth is also that I did not have a lot to discuss.  I just needed to know the current priorities of things on my plate.  My objective was to clarify my priorities, and the desired outcome that I needed at the end of our meeting was a list. 

Once this became clear, the meeting got a lot shorter.

How long ago was it that you attended a meeting with 3, 5, or 10 people without a clear understanding of the purpose and deliverable expected out of the meeting?  When was the last meeting you attended that got off track in the absence of a meeting objective?  How many meeting agendas have you seen that included extraneous items that wouldn’t have been necessary had a purpose been identified?  Most importantly, when was the last time you were sitting in a meeting that you might not have needed to attend if a clear meeting objective had been defined?  

The time it takes to be thoughtful about a meeting objective and desired outcome is not free, but it will always be cheaper than the time squandered in meetings without clear objectives defined.

So the next time you are inviting people to a meeting, consider identifying the objective of the meeting.  If someone were to ask you why your meeting is worth their time and organizational money, could you answer?  Maybe your objective is to get a decision about something.  Or identify options.  Or prioritize choices.  Whatever it is, define it first – before developing an agenda, deciding how long it will be, or whom to invite.

And then write down what it is you need to walk out of your meeting with, your desired outcome.  Maybe it’s a decision.  Or signatures of approval.  Or a list of options.  Whatever it is, write it down.  You’ll find your meetings are more likely to end on time because you know when they’re over – you’ve named it!

Try it.  But don’t expect to like it.  It’s a lot easier to just send an invitation to a bunch of people for a meeting about…you know…that thing we need to talk about.  

But once you have defined an objective, the rest of the meeting will become a lot more clear.  Your desired outcome will probably reveal itself.  Who really needs to be there will become evident – and will probably result in a shorter list of invitees than a meeting with no defined objectives.  Your agenda will begin to take shape and, again, probably be shorter than with an undefined meeting.

I ended up scheduling our meeting for 40 minutes, which is longer than we usually meet, but shorter than I initially intended to request.  I’m pretty confident it’s going to be a good use of organizational time and resources.  I think my manager is, too.

Is Your Meeting Worth the Time? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

A lot of project work gets done through informal, undocumented communication channels.  This is not only OK, it’s actually necessary.  Imagine if every conversation or information gathering effort we conducted required a documented plan.  The fact is a lot of good data can be mined from the water cooler and coffee klatch gatherings.

There are two types of this informal network: the grapevine and the rumor mill. I would suggest that while both are informal, undocumented communication channels and that they may include many, if not most, of the same people, they are significantly different.  The grapevine is an asset worth using; the rumor mill is something to avoid.  

How are they different and what makes one an essential part of a project manager’s communication strategy and the other a liability?  In my mind, it comes down to content and effect.

First, the nature of the content is qualitatively different between the two channels.  On the grapevine, information is  rooted in truth.  It may not include the whole story, but the information available is fundamentally true.  It is often a great source of information about prevailing attitudes, for example.  A project manager might tap into the grapevine to find out how people are responding to an organizational change of some kind. 

In addition, grapevine content is generally not specifically about individuals.  The vine is more about ideas and things, and less about who did or said what.

Content on the rumor mill, on the other hand, is highly specious.  Often the information obtained from the mill is patently false or so distorted by innuendo or editorializing as to be of little value. Of course, it’s not presented that way.  In fact, you can usually tell if you’re tapping into the rumor mill by a qualifying comment such as “My brother’s roommate’s cousin heard….”  The qualification serves the purpose creating distance between the information and the person spreading it; it’s a way of deflecting ownership for the information. 

Furthermore, the rumor mill is generally where you hear a lot about specific individuals and a lot less about ideas. Name dropping on the rumor mill is rampant – and generally not a place where you want your name mentioned. 

Still, it’s not always crystal clear as to which channel you are using based on content alone.  Effect is also important to consider in order to distinguish between the vine and the mill. 

The effect of the grapevine is positive (or at least not negative).  Use of the vine results in shared perceptions, level setting, or improved understanding.  The effect is not damaging or demeaning to others. When you are working the grapevine, you don’t feel uncomfortable about getting the information.  Grapevine conversations don’t inspire ducking into empty conference rooms to avoid being seen.  You come away from a grapevine conversation feeling like you could share what you learned with others without feeling like you violated a confidence or compromised anyone’s integrity.  You are comfortable with your name being associated with grapevine information.

On the other hand, the effect of the rumor mill is generally negative.  The purpose is really to provide cheap entertainment.  It’s the “You’re not gonna believe what I heard” factor.  When you are grinding on the rumor mill, you may look behind you or over your shoulder to see if anyone sees you.  These are the conversations that make you want to find an empty conference room or somewhere to avoid being seen.  Rather than about ideas or things, the rumor mill is almost always about people, and it’s generally not flattering.  The effect is usually that someone is shamed or demeaned or at least presented in an unfavorable light.

The savvy project manager will always make good use of informal communications channels in developing relationships with stakeholders, getting buy-in, managing expectations, and keeping the project on track.  The ethical project manager will know which type of informal channel they’re using, when it makes sense to use it, and when it’s best to disengage.

Grapevines and Rumor Mills – Assets or Liabilities? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

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

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

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

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

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

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

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

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

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

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

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

Happy Holidays!

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

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

If only it were that way with projects. Often, it’s the opposite with projects: our momentum peters out toward the end.  In fact, sometimes it feels like the finish line moves further from us the closer to the end we get. Starting projects seems relatively easy. It’s bringing them to a close that can be frustratingly elusive.

Yet, this is what makes a project a project, right?  It’s got a beginning and an end.  By definition, they need to come to an end so we can stop spending organizational resources on it and focus on other priorities.

Lessons learned from triathlon training can help bring projects to closure:

First, make sure you know what the project finish line looks like. 
What kept me going in my training and in the race was imagining myself crossing that finish line.  The finish on a project, of course, isn’t an actual line in the sand, but it should be clear to all stakeholders what “done” looks like.  Part of the reason we sometimes have a hard time getting to the end on projects is that we don’t recognize it when we see it.  Define it clearly; define it early.  And use it to visualize the end – just like a real finish line.

Second, measure progress regularly.
Training for a race is easy in that you can hop on a treadmill and gauge how far and how fast you are running.  As your endurance increases, your confidence and momentum toward the goal of completing the race increases. 

It’s not exactly that way on a project, but taking stock regularly along the way to know how you are doing relative to the objectives helps keep the “mo” on projects.  If at all possible, measure progress and let everyone know where things are at.  It’s usually not enough to just announce “done” at the end.  Nothing is more encouraging than hearing “we’re getting there” along the way.

Third, find a mentor.
Plenty of days during training I could have found something more desirable to do than swim, bike, or run.  Like laundry.  But I have a friend who had done this before and who always provided the right amount of support and encouragement when I was feeling uninspired.  Sharing my success with him was a treat.

Mentorship in project management can be every bit as powerful. Someone who has been there and done that and who will be sounding board as you work through obstacles to keep your eye on the prize can be a project manager’s greatest asset. 

Project closure is as fundamental to project management as running is to a triathlon. Visualizing the finish, regularly measuring the progress, and working with a mentor can help you achieve both.

Training for Project Closure was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

I hear this from project managers on a regular basis and it always brings me back to one of the truisms in project management: The project manager is responsible for project success. 

This is concisely articulated in the Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition:

As the person responsible for the success of the project, a project manager is in charge of all aspects of the project including, but not limited to:

• Developing the project management plan and related documents
• Keeping the project on track in terms of budget and schedule
• Identifying, monitoring and responding to risk, and
• Providing accurate and timely reporting of project metrics

This is reasonable and I teach this to my students.  Yet, it’s not enough to simply declare that the PM owns the success of the project.  There are numerous qualifiers to project success resting on the PM’s shoulders.  In this article, I’d like to focus on roles and responsibilities as it relates to ownership for project success: Specifically, a project manager’s ownership for project success or failure makes sense only when others take ownership for their part of the project, as well.

For example, sponsors have to own their role on the project.  What the PM needs from the sponsor may vary depending on the project as I’ve written about in other articles. But it’s generally safe to say that an unsponsored project leaves a project manager destined for failure.

In addition, team members have to own their responsibility for the quality of the work they do.  (If possible, the PM can replace poor performers on the project, but that’s not always the case.)  Mistakes or errors in execution don’t necessarily doom a project to fail. Requiring that the PM take responsibility for the work of others, however, will eventually make it difficult to achieve any agreed upon definition of success. Team members have to own their work results – good and bad.  

Third, everyone needs to own their role in communications.  The basic communications model includes responsibilities for senders and receivers of messages.  As the sender, the PM can send clear updates, ask well-defined questions, request specific information, and provide timely reports as planned.  Stakeholders also have a responsibility to clearly acknowledge updates, definitively answer questions, provide requested information, and consume project report information as planned.  This is simple on the surface, but often exceedingly difficult in practice.

None of this is news.  Roles and responsibilities are essential and there has been plenty written about the importance of doing so early to alleviate all sorts of project problems.

Yet how often do project managers feel like they’re being asked to win at a game of tennis without someone on the other side of the net?  They willingly own the project success or failure, but it doesn’t feel like others have been as enthusiastic in claiming ownership for their piece of the project outcome.

Make no mistake: I am not looking for a way for PM’s to abdicate responsibility.  In fact, it’s the PM’s job to make sure everyone is clear on all aspects of ownership.  So, yes, the PM owns the success of the project.  And the next time you hear one step up and say “Yes, I will own the success of this organizational investment of time, money and resources,” make sure everyone waits for the follow up request: “And here is what I will need from each of you.”

Who Owns Project Success or Failure? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

The Known Knowns you handle via the plan, but what about those various flavors of Unknowns?  How do you normally account for those things in the project?  Often it’s with padding – estimates that include unidentified amounts of time and/or money just in case. 

Let’s review how padding works: You ask your tech lead, Renee, for an estimate: “Excuse me, I need an estimate for that activity you’ll be doing.”  Now Renee may be thinking to herself “That will take me about 40 hours.”  But Renee doesn’t tell you that.  She may very likely tell you “Um, that’ll take about 60 hours.”

Why would she do this and, more importantly, so what?  First, she’s doing it to cover her Unknowns. And that is absolutely understandable. Stuff happens – Unknowns!  So what’s the problem?

Padding undermines sound project management practice in three ways:

1.   It undermines trust. The notion that it’s a good idea to under promise and over deliver may work once or twice, but over time padding undermines the trust between the PM and the team and the rest of the stakeholders.  Honest questions should inspire honest answers.  That’s how you foster partnerships.

2.   Have closets, will fill.  If Renee says 60 hours, she may very well take 60 hours and that’s opportunity cost.  She isn’t able to be allocated to other efforts. 

3.   Padding undermines the opportunity to learn from our experience, which in many ways is the essence of why we seek to develop good project management habits.  What you want to be able to do at the end of a project is turn around and look at the journey you took to get there and be able to take something away for next time. 

If you pad estimates and quite possibly end up with nonsense for baselines, what do you learn from that?  Certainly not as much as you could have had you started with meaningful estimates to begin with. 

Let’s say Renee is thinking 40 hours, she tells us 60, and then she comes in at 50.  What do you think?  Renee’s a star!   But what really happened?  She was 25% over!  If you are measuring against meaningless numbers, you don’t get much of a chance to make the PM journey a learning experience. 

Importantly, the intention here is not to highlight Renee’s failures.  Rather, the purpose is to identify and understand the Unknowns that derailed the work and consider how to avert those things in the future or plan for them next time.

This is all well and good, but Renee still has her Unknowns to contend with, so what might you do to partner with her to address those? 

The better project management answer to Unknowns is contingency reserves, an amount of money in the budget or time in the schedule seen and approved by management.  It is documented.  It is measured and therefore managed.  You draw from it where and when you need to and then learn from that, as well. 

The purpose of the contingency reserve is not to 100% cover everyone’s Unknowns, but rather to reduce them to a level that is acceptable to the stakeholders.  So maybe it’s 10% of the project total if stakeholders aren’t too risk averse and you feel bullish about what you know and don’t know.  Or maybe it’s 40% on a project with highly risk adverse stakeholders and a big box of Unknown Unknowns.

Knowns we can plan for.  The Unknowns?  We have two choices for how to deal with those.  Under the table with padding which precludes any discussion, measurement, or management of what contributes to the Unknowns.  Or Contingency Reserve in which  case we talk about them, document them, measure and manage them.  Only one way really enables us to learn from them.

Things We Know and Things We Don’t was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

It’s truly amazing to see 9-year-olds play hockey at the level that this team plays.  They skate on the ice as though they’re dancing on pavement.  They handle a stick with astounding skill.  They move the puck up and down the ice with agility that sometimes takes my breath away. 

It’s not hard to get caught up in this level of play and start cheering, shouting…OK screaming:  “Hustle!”  “Pass!”  “Move your feet!”  They are so good and they make it look so easy.  Fans sitting on the bench start to wonder, “What’s your problem? Shoot the puck!” 

Then after the game they come out of the locker room and you see them as…little boys.  With height not augmented by skates, bodies not donned in pads and equipment, faces not covered by helmets and masks, they’re just the little kids who like Saturday morning cartoons and still sleep with a favorite blanket.

If it doesn’t make you feel a bit silly for all the screaming you did, it sure does make you appreciate how good they really are.

Project managers don’t wear pads and helmets while managing projects and we don’t get a locker room from which to exit looking like a humbler version of ourselves to invoke appreciation for what we do.  

We do, however, get senior level folks to sponsor our projects and advocate for what we’re trying to accomplish.  We get access to resources, support to schedule and run meetings, and we may get training to help us do our jobs better.  We get teams of people and the wealth of organizational knowledge about what’s worked and what hasn’t on past projects.  So there may be stakeholders on the sidelines wondering, “What’s your problem? Deliver on time!”

Well, it’s tough out there on the project ice. Even when we get the sponsorship, resources, and skills we need to do our job, stakeholders are conflicted, organizations are in flux, and resources change.  While it may not look that hard from the bench, some days it’s amazing that we get consensus or momentum on anything. 

High expectations for project managers are a good thing.  But sometimes after a hard day, it would be nice to have a locker room where we could take off all the emotional and intellectual equipment we wear to get our job done and emerge for others to get a little different perspective for who we are:  someone just trying to get the project done for the benefit of the organization and everyone in it.

Hockey Players and Project Managers: Just Trying to Win was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

When you start telling people how to do their jobs instead of focusing on the results they create is usually an indication that you have stepped beyond the bounds of project control and into the realm of people control.

Some team members are quite adept at complicating this tidy distinction. What about, for example, the team member who tells you they will get the work done on time but sees no need to share details regarding the steps involved or how they’re going to get it done?

Even if it’s someone you have previously worked with and have every confidence that they’ll meet their deadline, it’s conceivable that you need more information about what’s involved in accomplishing the work. Perhaps for reporting or tracking purposes, for example, you may need to know about the steps involved or milestones in getting to their end result.

How can you ask for details that may not, in fact, be necessary to the person doing the work without being perceived as trying to micromanage? The most important thing is make sure the team member understands why you need the lower-level information. In the absence of an example or clear explanation of reporting or tracking requirements, many people are going to infer a lack of trust in a request for more detail than what they’re initially interested in providing.

The following three ideas can also help a project manager engage a resistant team member in providing more detail about their project work:

1. Suggest breaking down the work into smaller chunks to make it easier to share the work load or include others in accomplishing the result. If they decompose the work into smaller level activities or tasks, perhaps there are things that could be done by others.
2. Present it as an opportunity to teach others. If the team member can break down what it is they do to get their work done, it is easier to show and train others how to do it. Even if it’s not entirely repeatable, knowledge transfer requires some level of decomposition, and teaching others is usually an appealing personal development opportunity as well as valuable to the team and organization overall.
3. Consider the information in the context of risk. Breaking down the work presents opportunities for identifying risks that might otherwise be missed. Engaging the team member in that discussion may yield ideas that even they hadn’t considered in terms of possible threats.

When project managers have a need for more details than team members are initially willing to provide regarding the work they do, these perspectives can help soften resistance by showing team members how they can contribute to something rather than making them feel like they are being needlessly imposed upon or, worse, not trusted.

So go ahead ask: “Tell me more about what’s involved in getting that done.”

Control Projects or People? It’s All in the Details! was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog