
· Select the right people
· Set expectations
· Motivate the people
· Develop people
Describe. Debate. Decide.

Project Managers of successful large IT projects spend relatively little effort on activities declared important in project management literature, methodologies, and training seminars. Only two of the nine initial assumptions, dedicated project team and frequent interaction with stakeholders, passed the 80% bar (see posting on June 15, 2009).
internal and external), and users exhibiting ownership of project outcomes. There was the consultant who volunteered to cancel his contract if a software release was not successfully executed at a critical time. I also remember the CEO who found a project team in the office hours after a blizzard ended. No one from the rest of his company could make it into the office because of the snow-drifted streets. Have you also had difficulty describing how leadership contrasts with management? Pawel Brodzinski tackled this question here. Do you simply know leadership when you see it?
I was dumbstruck. In all of my project management courses and seminars, studying of PM textbooks, and discussions with senior management, I had never come across the importance of leadership, instilling a sense of ownership, and cultivating an environment of trust. After all, most of our status reports address schedule, budget, and risks.
When was the last time your boss asked you about your project team members’ sense of ownership? When has your status report commented on your client/customer’s trust in the project team?
Thank you for visiting Management House. I look forward to reading your comments.
The final assumption that I tested in my project management research project (introduced in a Jan 25, 2009 posting), was a project’s collection and use of lessons learned. I wondered whether a difference between project success and project failure might be that a successful organization might learn from its own successes and failures.

My experience with lessons learned is limited to a one-time meeting at the end of the project, where what is discussed (i.e., lessons) is largely or entirely ignored the next time around. When have you send lessons learned used? Has it made a difference?