Kimberly Wiefling is on a leadership blogging kick this week over at the UCSC Extension in Silicon Valley’s “Art of Project Management” blog. Manage Cows, but LEAD People talks about the difference between management and leadership. Her post points out that just because someone is in a high level management position, that doesn’t mean they act like true leaders.
Sometimes leadership and management are put forth as a false dichotomy. They are really separate activities that can exist alone or together. When I first started managing people, I remember going to leadership training and how many managers insisted they were not managers at all, but leaders. That always seemed strange to me. Why does it have to be either/or?
You can be a manager without being a leader. You can be a leader without being a manager. If you have skill in both, they can create a synergy and really get people motivated and effective. In fact, I’m not even sure you can be a truly effective leader without great management skills, and vise-versa.
What are your thoughts on how leadership and management relate to one another? Please, leave a comment!
Anita Wotiz is the guest blogger 
this week over at the UCSC Extension in Silicon Valley Project Management blog. She published great post titled “An unrepeatable success?” Read it here.
It was great to hear about the project, specifically the lessons learned and trying to relate them to my own experience.
I wouldn’t write the first set of factors off as things that can’t be duplicated. Sure, it’s easier in some cases because these things fall into your lap, but these can be influenced to some extent. Paraphrased:
- Good team (competent, cooperative) –A PM can sometimes influence who works on their project, and ensure they are competent. Cooperation and team spirit is largely influenced by the PM, in my experience.
- Exciting work –Not every project is glamorous on the face of it, but the PM can and should figure out how to position the product being created to the team by selling them on how much value it will add for the end users, and how their individual and team contributions make it possible.
- Full access/utilization of previous work –Again, this usually doesn’t fall in your lap, but it’s amazing to me how many project managers don’t spend enough time during the planning phases trying find previous work that can be re-used. Many seem to want to re-invent the wheel with each project.
As for the other factors, paraphrased:
- Don’t constrain the project to a preconceived solution –Three points; I see this so many times, where the sponsor and stakeholders have a preconceived notion of what the solution should look like before they even fully understand the problem! Granted, sometimes there are real constraints that are necessary. I think it’s human nature to start coming up with possible solutions very early in the process, and difficult to avoid. Personally though, I’ve found the best results come from forcing yourself to focus strictly on the need/problem during early planning, including the charter, preliminary scope statement, and initial requirements gathering processes.
- Good WBS creation and decomposition, bottom-up estimating –Bingo! This agrees completely with my experience about what helps make a project successful. I’ve had a lot of luck in the past using a delphi-style method of estimating, where we go through each task in a room with the experts who will be performing them, and each person writes down an optimistic, likely, and pessimistic point estimate. I take all the estimate sheets afterwards and roll them together, ask about any outliers, and can usually come up with pretty good ranged estimates with a solid grasp on standard deviation and confidence levels.
- Management cost/time buffers available –I agree that it’s critical for the sponsor/customer to realize that buffers are there for a reason…they are not just downtime or waste, they are crucial components of a good project that can handle the inevitable risks that will arise.
- Collaboration –It sounds like Anita was able to get the whole team to collaborate on scheduling by using post-it notes on the wall. I think that is excellent, although alternative methods may work just as well to have the team collaborate on schedule and task dependencies.
- Iterative Development –This is a benefit I’ve used and seen in my projects too. If you can push out iterative releases that are functional, you can start getting feedback from the customer and make subsequent development based off a real foundation, instead of a theoretical one. Writing code to specs is one thing, but if you can immediately test it against an initial release of the pieces it has to integrate with, you’re way ahead of the game.
