A couple of years ago I did an interview on what a manager can do to regain trust when he or she has screwed up royally.  I thought the points were particularly pertinent to many of my subscribers so I thought I'd print excerpts from the interview here:

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.

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.

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. 

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

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.

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.

This part three of a three-part series on Mastering Credibility.  Part one is It's What You Know and part two is It's The Relationships You Build.

Bert was an associate at a premier management consulting firm.
Over the years he specialized in providing advice to senior management in information technology organizations.  Generally he had some pretty insightful ideas that many of the rank and file in the client organization viewed as a bit theoretical.  His advice was typically accompanied by general implementation timelines which client organizations rarely took verbatim.  Bert's advice usually culminated in some type of a Powerpoint presentation to the senior client management; then it was off to the next assignment.

For years Bert had been trying to get a foot into the door of Laner Robotics.