Some time back I spent about three hours writing and doing emails at one of our local malls. I love this place because there are lots of tables to sit at and the mall has free wireless access so I can be online all the time. As I was exiting the mall I noticed a woman about 20 feet away from the entrance heading into the mall. As I walked out the door I held the door open for this woman for a few seconds. As she walked by me into the mall she said "WOW!" She was surprised that I actually took three seconds out of my life to hold a door open for a complete stranger. Imagine what I could have done with those three seconds that I wasted :-).
Project management is changing….it's becoming more strategic, more mainstream, and not just synonymous with technology implementations. Today's PM needs to be more than technically adept or be able to whip out a gantt chart. Get a read on some of these crucial skills the everyday PM will need to succeed:
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:
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:
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.
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.
Contact Lonnie about article reprints. Please specify article you wish to reprint.
See Lonnie's Amazon Author Page