Skip to main content

Tag: Career

Want to Earn Six Figures? Become a Project Manager

NEWTOWN SQUARE, PA, 16 December 2011 — As employment continues to fluctuate, uncertainty about job stability and the economy is keeping people on high alert. Despite these uncertain times, there is a silver lining for those in one profession that continues to thrive. New research from the Project Management Institute confirms what businesses, job boards and the media have been proclaiming for the past two years: project management is one of the hottest professions out there.  According to the PMI Project Management Salary Survey, Seventh Edition, the salaries of project managers around the world continue to climb, indicating not only that project management professionals are in strong demand, but also that organizations are increasingly recognizing the value of trained project managers to their overall business goals.

Location and certification increase salaries

This year, 30,000 project management practitioners in 29 countries responded to the survey. The data was reported across all roles and experience levels.

·         The median annualized salary is US$92,000; in the U.S. it is USid=”mce_marker”05,000.

·         71% of respondents reported that their total compensation (including salary, bonus and other benefits) had increased over the previous 12 months.

·         Nearly 33% reported increases of at least 5% of total compensation in the last year.

Countries including the United States, Germany and Australia posted average salaries well above the median, each exceeding USid=”mce_marker”00,000. The highest project management salaries in 2011 are reported from Switzerland, where respondents averaged more than USid=”mce_marker”60,000. 

The 10 countries reporting the highest median salaries (reported below in US dollars) are:

·         Switzerland, id=”mce_marker”60,409

·         Australia, id=”mce_marker”39,497

·         Germany, id=”mce_marker”10,347

·         The Netherlands, id=”mce_marker”09,775

·         Belgium, id=”mce_marker”08,750

·         United States, id=”mce_marker”05,000

·         Ireland, id=”mce_marker”01,635

·         Canada, $98,517

·         United Kingdom, $96,384

·         New Zealand, $91,109

The survey shows that certification, as well as geography, positively affected salaries. Project Management Professional (PMP)® credential holders in the U.S. earned an average of 16% more (approximately USid=”mce_marker”4,500) than their non-credentialed peers in 2011.

Project management is increasingly important to organizations

“These numbers are great news for project managers who are looking to expand their careers with new skills, individuals who may be interested in a career change and those who are coming out of school or military service and considering what job would best suit their future goals,” said Mark A. Langley, President and CEO of Project Management Institute. “There is a very real benefit for those with the experience and training to pursue certification. In today’s volatile economy, organizations are increasingly recognizing project management as a professional competency that provides distinct competitive advantages – and they are willing to pay for top project management talent.”

Created and conducted by PMI’s market research team, the PMI Project Management Salary Survey, Seventh Edition, provides a comprehensive look at compensation in the global project management field, measuring salaries across eight major position description levels in 29 countries. The full report is available on www.pmi.org.

 


About Project Management Institute (PMI) PMI is the world’s largest project management member association, representing more than 600,000 practitioners in more than 185 countries. As a global thought leader and knowledge resource, PMI advances the profession through its global standards and credentials, collaborative chapters and virtual communities and academic research. When organizations invest in project management supported by PMI, executives have confidence that their important initiatives will deliver expected results, greater business value and competitive advantage. Visit us at www.PMI.org, www.facebook.com/PMInstitute and on Twitter @PMInstitute.

 

7 Trends in Business Analysis and Project Management to Watch for in 2012

Graph_PresentationThe close of one year tends to make one reflect on what has occurred in the past year related to 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.

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.
    • 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.

    • 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.

    • 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:
      1. 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.
      2. 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.
      3. 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.
    • 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:
      1. 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.
      2. 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.
      3. 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.
    • 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.
      1. 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.
      2. 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.
      3. Collaboration tools have 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.
    •  “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. 

     Don’t forget to leave your comments below.


    About the Authors

    Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

    Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

    Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

    Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

    Start off Your New Year with a Quick Win

    As we start off the New Year, it often takes a while to get back into the swing of things.  Thus, project results can become delayed or dampened while ramping back up to speed.  Instead, in today’s new normal business environment, where sales are lackluster and cash is tight yet service is paramount, there isn’t a moment to lose on achieving critical project results. 

    One of the best ways to accelerate project results is to orchestrate a small, quick win.  A quick win gives the project team a reason to celebrate success and become re-energized on the project objectives.  It reminds the team of where they left off, why the project is important to the executives and company objectives, and it gives the team members a way to kick off the New Year with recognition.

     Undoubtedly, there are countless quick win possibilities for every project team yet achieving them when you need them can be a challenge.  So, what are a few tips to ensure your project team achieves a quick win?  1) Reengage.  2) Ask Questions.  3) Pick a “win”.

    1. Re-engage:  First, you must reengage your project team!  Don’t expect your team to continue where they left off.  Even if they wanted to do this, there have likely been too many distractions over the holidays.  Instead, kick off the New Year by bringing your team together. Reengage with them.  Back up for a few minutes and discuss why the project is valuable.  Recognize each team member for their part of the project success thus far or their key role in the project.  Remind the team of the critical path and where they left off.  And last but not least, reengage as the project leader.
    2. Ask Questions:  It’s surprising how simple it is to ask questions yet this secret to success is often overlooked.  First, find out where you project team stands.  Ask them what they think is most important to ensure success?  Is timing critical?  Resources?  Overlap with other departments or external resources?  Encourage debate and brainstorming.
      Find out which are the most critical upcoming tasks. Why? Is everyone on the same page? If not, why not? Should we incorporate any tweaks given the progress so far?  Ask about potential roadblocks. Listen carefully.
    3. Pick a “win”:  Choose a small, quick win as a project team.  Most importantly, ensure everyone is on the same page.  Ensure everyone has an opportunity for input and feedback. 

    Then, develop or clarify a plan to achieve the quick win.  Make sure the leader of each project task understands its importance.  Communicate in advance that a critical path task is coming up.  Encourage teamwork.  Do not dictate; instead, participate. 

    Plan to celebrate the win.  Begin promoting the importance of the quick win immediately to key stakeholders and executives.  Your #1 job as project leader is to ensure the quick win is perceived as a quick win!

    The power of a small, quick win is incredible – there’s nothing like it to gain momentum.  It isn’t complex, expensive or time consuming yet it can propel your project forward in the New Year.  Why not reengage your project team to plan a quick win immediately?

    Don’t forget to leave your comments below.

    Seven Crucial Steps to Effective Project Risk Management

    FeatureDec14thRisk Management is simply defined as identifying, analyzing and managing the uncertainties in a project -both positive (opportunities) and negative (threats). The benefits of risk management are instrumental to a project’s success. By proactively addressing uncertainties, in combination with a strong project management program, problems within the project can decrease by as much as 60 or 70 %.

    The International Organization for Standardization identifies the following principles of risk management.

    Risk management should:

    ~ create value ~ be integral to the organization process
    ~ be part of the decision making ~ address uncertainty and assumptions
    ~ be systematic and structured ~ be based on accurate information
    ~ be project specific ~ account for human factors
    ~ be transparent and inclusive ~ be responsive to change
    ~ be periodically re-assessed

    But what are the steps to building an effective risk management program?

    1. Embed risk management as an integral part of the project. Stakeholder buy-in and support is very important to achieve a successful risk management process. It is a good practice to ensure that there are demonstrable benefits to illustrate this approach and make risk management part of the day to day operations.

    2. Identify Risk. This step is most effective when done very early in the project. Having a brainstorming session with team member to list out several potential risk items is a good beginning. Include all potential risks, including the risks that are already known and assumed, such as scope creep. Include threats that may stem from human threats, operational issues, procedural impacts, financial threats and natural events. Talk to the industry experts who may have experience in your project type to get a different perspective.

    Identify not only the threats, but also any opportunities that may impact your project. Opportunities may assist you in bringing the project in on schedule, perhaps with better deliverables or make it more profitable.

    Communication at this stage is crucial. Including communication of risk as part of all meetings is effective to illustrate the importance of risk management, share the risk potentials and provide a platform for discussion.

    3. Assign Ownership. Who is going to be responsible for what risk? This person will be accountable to optimize a specific risk-either decrease the threat or capitalize on the opportunity. They will identify the possible triggers to their assigned risk.

    Assigning ownership is also important in establishing an effective and clear communication channel. All involved with the project know whom to call when questions arise.

    4. Estimate or Prioritize Risks. Once the risks are identified, the next step is to assess the likelihood of the threat being realized. Some risks will have a much higher impact. One approach to estimating the risk is to make a best estimate of the probability and multiply this by the amount it will cost to set things right, if it happens. This will provide an impact value associated with the risk. Another approach is to assign each risk a numerical rating, such as a scale from 1 to 5. Do you have any potentially large events that can cause huge losses OR gains? These will be the number one priorities. Ensure that your priorities are used consistently and focus on the biggest risks first and the lesser priority risks as applicable.

    5. Analyze the Risk. What is this risk about? What are the effects of this risk? What causes will make this risk occur? List the different causes and circumstances that affect the risk likelihood; doing a simulation to illustrate how likely the project is to finish on a specific date or at what cost. Gaining a sound understanding of the risk is a solid foundation for an effective proactive response and provides insights to manage the risks.

    6. Manage the Risk. Plan out and implement a response for each risk. Typically you will have four options – Transfer the risk (subcontracting scope or adding contractual clauses), risk avoidance (eliminating the source of the risk, such as changing a vendor), risk minimization (influencing the impact) and risk acceptance.

    Create a contingency plan for the largest risks. This would encompass all actions taken if a risk were to occur.

    7. Create a Risk Register. This will enable you to view progress and stay on top of each risk. A good risk register or log will include a risk description, ownership, and the analysis of cause and effect. This register will also include the associated tasks. A good risk register is a valuable tool in communication project status. It should be easily maintained and updated. By remaining current and up to date, the risk register will be viewed as a relevant and useful tool throughout the project lifecycle.

    Once a solid risk management process is established, it forms the basis for crisis prevention and cost effectiveness. Risk management involves adapting the use of existing resources, contingency planning and resource allotment. This process does not need to be complicated. By implementing a project risk management process at the beginning of each project, the team can prepare for whatever may occur and maximize the project results.

    Don’t forget to leave your comments below.


    Josh Medica, CEO and President of Integrated Consulting. Josh’s passion and commitment to project excellence has established him as a project management/project controls industry expert. He transferred that passion and knowledge into executive level master training classes on all topics related to project management and project controls.  Josh has facilitated risk workshops on projects ranging from id=”mce_marker”0 MM to $2 BB .  His dynamic and thought provoking presentation style has positioned him as a leading trainer/educator. His speaking circuit also includes house training for large EPC companies, engineering companies, and major oil companies across the globe.

    The Agile Project Manager – Don’t Throw out the PMBOK!

    Dec7bob4I must admit that I’m a fairly rabid agilist. Part of the rationale for that is the pain I’ve experienced in leveraging traditional PM techniques in software projects. Another influence is my experience dealing with traditional leadership and the dysfunction relating to driving projects and teams towards unrealistic goals.

    What’s interesting though is a conversation I had with our Scrum Master team the other day. I asked them to act more like “traditional project managers”. To begin to—

    • be more prescriptive at times with their teams; demanding high quality, excellent software, and adherence to our agile principles
    • pay close attention to risks – planning, real-time surfacing and guiding team reactions
    • encourage the teams to improve at an accelerated rate; to set the bar high for improvement
    • become visible as leaders and spokespersons for their teams; to do a better job of socializing state & progress
    • take the role of impediment resolution to the next level; mining for impediments…and dependencies, then inspiring action
    • cheerlead for their teams; inspire and demand that the Product Owner does the same

    What I was trying to convey to them was the ‘mindset’ of a “good Project Manager”…or at least the ones I’ve seen and collaborated with in my journey. You see, many agilists use the role of Project Manager as a bit of a verbal “punching bag”—implying that there is no need for them in an agile context. By the way, you see these same folks trivializing other roles too—functional managers, testers, and business analysts to name a few.

    I can’t disagree more with these folks and that position. I think solid Project Managers can find a place in agile teams…a place that makes a HUGE difference. Yes, they might need to reframe their style and behaviors for an agile context, but please, please, please don’t throw away all of your approaches. Your teams absolutely need and will appreciate your skills, as long as you reframe appropriately without throwing out your essence!

    The “Agile Way”?

    An anti-pattern that often shows up in agile teams relates to managers and project managers losing their way when it comes to knowing when and where to engage their teams. Knowing how to effectively handle the fuzzy and scary notion of a “Self-Directed Team” it turns out can be quite challenging.

    A common reaction is to treat the team as if walking on egg shells. If you see the team heading for a cliff, you can’t really say anything—as they’re “self-directed”. Of if you do say something, you must whisper…quietly…hoping that someone might hear you.

    I once coached a team in Toronto. As is my typical practice, I gave them a quick Scrum overview, then planned and kicked off their first sprint. I stayed for a few days to ensure they were going in the right direction, and then I went home. I came back at the sprint transition just to see how things were going. In my first morning Scrum upon returning, one of the developers sort of “yelled at” their functional manager who was attending as a ‘Chicken’.

    The team was stuck at a technical impasse and she said: “You better step in and tell us how to handle this, or I’m going to scream”. I was taken aback and after the stand-up I asked her what was up.

    She said that ever since the sprint started that none of the functional managers were saying anything—nor providing any guidance whatsoever to their teams. And that she was sick and tired of it. She wanted help! I then asked the functional managers what was going on. They said that they were only doing what I’d told them—that the team was “self-directed” and that they were to keep quiet…being ‘Chickens’ if you will.

    Ugh I thought as I smiled a wry smile to myself. Yes, I had told them that respecting self-direction is important. But that doesn’t imply that you don’t have a role and responsibility as the teams’ functional manager. You certainly don’t let them crash into a wall without yelling and warning them. You see, the managers missed the nuance of leading within agile teams, as many roles do. They mistakenly behaved as if they were marginalized and didn’t matter…when nothing could be further from the truth!

    Dec7bob3

    So—Which way do we go George?

    It’s Situational & Skills Matter

    Always remember that your agile PM role is situational. You’ll want to keep the values (Lean principles, Agile Manifesto Principles & Practices, Essence of your specific methods, Quality, and focus on Team) core in your thinking, but at the same time very much react to situations as you always have—with simply some ‘adjustments’.

    As part of being situational, always remember that the teams’ skills & experience matter quite a bit in how you should react. If you have a brand spanking new team, then you probably want to provide more prescriptive guidance. If you have a master-level team, then your job is to softly guide & support them, but truly get out of their way. The Dreyfus model of skill acquisition is a good model to become familiar with to conceptualize the various team levels that you might encounter and to guide your adjustments.

    Risk an Opinion

    As in the above story, your teams still need leadership—leadership that provides clarity, vision, missions, and goal-setting. Leadership that is “in the game or trenches” with them. Leadership that endeavors to protect them and to shield them from major obstacles and mistakes. Leadership that is supportive and encouraging. Leadership that is in all cases, well, leading them…

    In a word, you should evolve towards a more Servant-Leadership style. But you also need to share your thoughts with you team. Risk saying how you feel and what you’re concerned about, but then allow the team to take risks and chart their own paths. Risk telling the team ‘No’ if you feel they’re on a destructive path and be prepared to also tell them ‘Why’. Finally, risk ultimately becoming a part of the team and sharing their responsibilities.

    Leverage your Instincts

    As I’m writing this, my company iContact is making a fairly major release of our eMail Marketing software platform. We’ve been adding social capabilities for several months and are now exposing them via this release.

    One of the things we struggled with was how we turn on our +70k customers. Do we do it all at once, or in a more measured way to mitigate risk and allow us to see how the new functionality ‘behaves’ under load. There were two schools of thought across the teams—release it ALL and release it incrementally. Most of the teams had an ALL perspective, as did our QA team members. However there were a few in the development organization that wanted a more controlled release and argued for that option. Initially they were considered naysayers, only reacting to FUD, but to our credit—we listened to them.

    After much discussion, we opted for a controlled roll-out. While we didn’t encounter huge problems as we ramped-up, it allowed for us to better understand our usage metrics, plan for incremental use, and have time to fix a few lingering issues. In the end, it proved that our overall risk-handling instincts were the right way to go. I’m glad the few had the courage to “speak up” and that we trusted their instincts.

    Ceremony & Reporting Matter

    Remember that even agile teams still bear a responsibility to integrate back into the organization. They need to be transparent and communicative—and not simply in agile terms. It’s not sufficient to simply say “come review our burndown chart” or “just attend our Daily Scrum” if an executive or stakeholder asks you or the team for status.

    Sure that is a mechanism or ceremony setup for this sort of communication. But what if that stakeholder doesn’t show up? Does that alleviate your communication responsibilities? Of course not! So beyond the information radiators, a PM can ensure the team is effectively communicating broadly across the organization.

    Another important point is communicating in ‘terms’ that the business can understand. Whether it is reports, data, videos, or whatever it takes to represent the teams’ progress and efforts.

    The PMBOK!

    I’ll even go so far in this post to say that many of the ‘traditional’ principles and techniques from the PMBOK shouldn’t be “thrown away” from an agile perspective. Let’s take the notion of critical path for instance. In larger agile projects, with multiple teams, there still are plans that evolve. And within that framework keeping the critical path of work in-sight across teams can be a crucial visibility point.

    As can asking the team to manage risks, or creating a project charter, or establishing effective milestones for cross-team integration. So please don’t throw away or ignore these skills if you “Go Agile”. Just transform them (and yourself) a bit and then trust your instincts in the situations that emerge.

    Wrapping Up

    I want to wrap-up this post with caution though—traditional Project Managers DO need to reframe themselves and their approaches in an agile context. Throw away your templates and checklists that prescribe a specific approach to all projects & teams. Instead you must become context-based and situational in your approaches.

    You must also engage your teams, not as an execution monitor or policy cop, but as a true partner.

    I’ll leave you with the following two charts that nicely illustrate some of the focus and tempo changes that occur between Traditional & Agile PM activities.

    Dec7bob2Dec7bob1

    So, Project Managers—may you navigate these waters well and engage with your teams. They NEED YOU!

    Thanks for listening,

    Bob.

    Don’t forget to leave your comments below.