It's happening more and more; managers are being asked to manage virtual teams of people that may or may not have a direct reporting relationship to the manager.  Some find it easy to do, but many others find it difficult to garner the respect from team members who don't have to follow the manager.  Get a few helpful tips to help you next time you're asked to manage a virtual team.

Excerpted from Six-Word Lessons to Avoid Project Disaster

As a young hot-shot information technology (IT) project manager I was convinced that I had it all together. I was bound and determined to show all those more senior to me how to deliver successful projects. It wasn’t until I messed up not one, not two, but three projects simultaneously that I grew up and recognized I wasn’t all that I thought I was. While that period in my professional career was particularly painful, it was also some of the best learnings I could have gone through. Since then I’ve had successes and failures, but the failures became less frequent because I learned to get comfortable with others providing a critical eye on my work and helping with the necessary precision questioning to keep me out of hot water. This is the genesis behind Six-Word Lessons to Avoid Project Disaster.

Following are 15 lessons focused on the project sponsor and the questions to ask to ensure active, focused, and engaged project sponsorship.

1. Lesson 1 - There was no project sponsor assigned - A non-existent sponsor translates to poor support from a business organization, particularly when higher-priority work emerges. Question to ask: Does the project have an engaged and committed sponsor who feels the pain of the as-is situation?
   
2. Lesson 2 - Sponsor didn't advocate with his organization - A poorly advocated project translates to inconsistent business organization support and confusion as to what the sponsor expects. Question to ask: Has the sponsor effectively communicated the project scope and goals to his/her organization?
3. Lesson 3 - Sponsor lost interest in the project - A sponsor losing interest is usually an indicator of business priorities changing or the sponsor's management having weak interest. Question to ask: Does the sponsor remain committed to the project and his he/she continuing to support the PM and the team?
4. Lesson 4 - Sponsor changed; new one didn’t care - Sponsor change mid-flight can also be accompanied by different priorities or marching orders. Question to ask: Does the new project sponsor care about the project?
5. Lesson 5 - Sponsor wouldn't meet with the PM - Sponsors who don’t make themselves available to a PM typically mean the project is either not important to the sponsor or the sponsor has bigger fish to fry. Question to ask: Is the sponsor cancelling meetings or not making him/herself available to the PM when the PM needs him/her?
6. Lesson 6 - The sponsor kept changing project scope - Unanticipated scope changes from the sponsor typically mean scope is not physically written down and agreed upon or “selective memory” on part of sponsor or PM.  Question to ask: Is the scope statement clearly documented and regularly reviewed with the sponsor and PM?
7. Lesson 7 - Sponsor wanted elegance versus "good enough."- Over-polishing the apple on features can contribute to cost and schedule overruns. Question to ask: Are the features meeting the need without additional bells and whistles that are beyond “good enough”?
8. Lesson 8 - The wrong users were on project - Putting the wrong users on a project can create gaps in capabilities that get discovered after solutions late in the development life cycle. Question to ask: Are people accountable for in-scope capabilities represented on the project?
9. Lesson 9 - The sponsor wouldn’t make difficult decisions - Sponsors unwilling to make difficult decisions contribute to solutions that won’t align to to-be business needs. Question to ask: Are there outstanding issues assigned to the sponsor that are going unresolved?
10. Lesson 10 - Sponsor wouldn’t kill project not needed - Priorities change. A project once deemed important may not be important due to shifting priorities or environmental changes. Question to ask: Does the project still address a problem the sponsor and his/her management sees as important?
11. Lesson 11 - Major policy changes needed weren’t understood - Sponsors who don’t understand and act on mandatory major policy changes can create business failures once the solution is implemented. Question to ask: Are policy changes clearly documented and is the sponsor being held accountable for driving the policy change?
12. Lesson 12 - Sponsor got too overconfident with scope - Some sponsors can get overconfident if the project appears successful by squeezing in additional scope items, causing potential issues with delivery if things go wrong at the end. Question to ask: Is the sponsor asking for additional work to be done late in the project which could jeopardize schedule?
13. Lesson 13 - The sponsor didn’t secure the funding - Sometimes funding takes a back seat to getting something done on time. If the funding isn’t secured by the sponsor, the team risks an overrun or unplanned staffing reduction midflight. Question to ask: Has the sponsor secured the funding to get the project done?
14. Lesson 14 - Sponsor wasn’t clear on the problem - Not articulating a clear problem to be solved can lead to increased scope due to chasing “shiny object” problems. Question to ask: Is there a clear, quantifiable problem statement that clearly defines what project success looks like?
15. Lesson 15 - The benefits didn’t justify the cost - The sponsor needs to ensure that the expected benefits support the cost of getting the project done. Ideally a financial analyst develops and certifies the cost/benefit analysis. Question to ask: Is there a clear cost/benefit analysis that is updated at key project milestones to ensure project makes financial sense to do?
    

Want to know the ten most important attributes of a best-in-class project sponsor? Check out Be a Killer Sponsor.

Lonnie Pacelli
Keynote Speaker | Board Director | Autism Advocate | Author | Project Management Expert | Microsoft/Accenture Veteran 
See his books on Amazon.

As a child and young adult I was very independent.  Regardless of the situation, if I was doing something I was determined to do it myself and not ask for anyone's help.  In my eyes asking for someone's help was akin to admitting defeat or somehow showing others that I was weak or incompetent.   My attitude was "If someone else can do it, I can do it".   How Naive.

 A couple of years back I was engaged on a project to help recover an agile project run amok.  The project was one of the first in the organization to use an agile development methodology and consisted of eight four-week sprints with six capability development teams.  The project manager was a very theoretical scrum master who was more concerned with having an agile "design win" than he was with ensuring the business sponsor was satisfied with the project result.  After about the third sprint there were significant issues with capabilities not working together, interfaces with external systems breaking, and problems with meeting sprint dates for committed capabilities.  To save the project, we had to take a number of steps that violated the purist agile model but were necessary if we were going to keep moving forward on the project.  Our implementation looked like a mishmash of agile and waterfall.  It wasn't pretty, but we eventually got the project done.

Since Microsoft Project's initial release in 1984 it has evolved  into an incredibly powerful and sophisticated project management tool.  One of those sophisticated features is calendars.  As one of my heroes  Spiderman says, "with great power comes great responsibility".  As a project manager, you can exploit some of the cool capabilities with Microsoft Project calendars, but beware, you could really tie your shorts up in a knot if you start getting too fancy with project calendars.  In addressing this topic, I want to start off by telling you what Microsoft Project help says about calendars then give you a few tips to help you avoid Project Manager hell when trying to develop a meaningful and realistic project schedule.      

Excerpted from The Project Management Advisor - 18 Major Project Screw-Ups And How To Cut Them Off At The Pass (Prentice Hall, 2004)

Virtually every (rational) project has at its core a need to solve some problem that is perceived by someone.  Problems can manifest themselves as barriers to getting something done (“we can’t possibly ship 10,000 units/week with our existing systems”) or as opportunity to doing something better (“we need to reduce the cost of processing purchase orders by 20%”).

In any event, there is a desire to do something tomorrow that can’t be done acceptably today. Admittedly, some of the most fun projects that I have worked on have been the “omigosh, we need to get this done or else” projects.   I have seen the greatest clarity of purpose on projects where there was a very real and tangible consequence to not completing the project successfully.  One outstanding example of this that affected virtually every business on earth was the Y2K computer scare.  One of my jobs was in ensuring that our mission-critical vendors were adequately prepared for Y2K and that there would not be any business interruption to our company as a result of a vendor’s failure to perform.

Begin rant.

Recently I've noticed a trend which frankly really ticks me off.  My observation is that more and more project managers are becoming hyper risk-averse and demonstrating an unwillingness to accept accountability for the projects they manage.  One tell-tale sign which I've noticed is the usage of "matrixed" organization charts.  In matrixed organization charts, the project team is depicted using different types of team leads shown vertically and horizontally on the organization chart.  With a matrixed organization, team members may have a "solid line" reporting relationship to one manager and a "dotted line" reporting relationship to one or more managers.  Now, I fundamentally don't have a problem with the collaboration aspect that a matrixed organization enables; where I do have a problem is when the matrixed organization makes it difficult to pinpoint who has accountability for the project. 

On a recent project my company was working with a frozen seafood manufacturer to help them bring a specialty frozen seafood product to market.

A huge component of getting this project done was the packaging; it had to be eye-popping and appealing while protecting the frozen seafood pieces inside.  After a number of design sessions with the packaging manufacturer, we received the finished packaging.  What was initially exuberance during the design session turned into disappointment when we saw the finished product.  Some of the graphics were a bit blurry, a re-sealable zipper wasn't included, and a clear window to view the contents inside was missing.  Our emotions went from disappointment to anger as the manufacturer told us it would be a number of weeks before a new delivery of the packaging could be done.  If we took this route, a key delivery to a very important customer of ours wouldn't be met.  What a pickle.