I’m a huge fan of sausages. Whether it be Italian, bratwurst, chorizo, kielbasa, or andouille, I love the seasoning and the snap of the casing when you bite into it. Now I know that the stuff that goes into sausage is of the most undesirable parts of the animal including organs, guts, head, and other parts that I prefer not to think about. I have never had the opportunity to see sausage being made, and as a matter of principle; I don’t want to because I know I’d be grossed out and it would ruin my appetite each time I enjoyed a banger. I choose to remain blissfully ignorant about the sausage making process.

Just about every seasoned project manager has experienced at least one failure in his or her career. I am always skeptical of the experienced PM who says "I've never failed".  They're either lying or don't have experience. Some of my best (and most painful) growth as a professional occurred because of a failed project. Project managers can redeem themselves and maintain credibility by doing the following:

Secrets of success?  Oh puh-leeze.  There aren't any secrets of success in my opinion.   Success is achieved through things that we've been taught to do for years and years.  Good old-fashioned hard work is one of your strongest foundations to ensure meeting your life goals.  In addition, building the following pillars on the foundation of hard work will increase the likelihood that you can meet those goals and achieve your dreams.  Check out these four pillars and see if any resonate with you:

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.

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.