It is time to start a new, more serious, and much-needed debate. Who are the top five non-religious mythical project managers ever? My first pick? Santa Claus.
I mean really, how many of you can say that if you missed your project deadline by one day, you would disappoint 6.89 billion children? That is quite a bit of pressure! Not only that, missing the deadline likely would stop his existence! As some of the great texts will tell us (by texts, I mean movies and TV) children must continue to believe in Santa Claus for him to continue to have the magic. I teach in my seminars to ask the question, "Can I ask the significance of the date?" when a mandated date is posed. Santa can answer, "My very existence will be diminished and I will crush the hearts of billions of children." I think that constitutes an acceptable reason to mandate a date.
So every December 26th, Santa and his team of elves hold a lessons learned session to begin the planning for the next project and literal "go-live" date of December 25th. I wonder if the elves are looking at Scrum and Agile methodologies for toy making?
There have been some interesting situations that Santa and the elves have discussed during lessons learned of the past. Like the one time in 1947 that Santa had to go to court to prove that not only did he work at Macy's, but that in fact he was the real Santa. The Commonwealth of New York agreed.
Contingency plans have been put in place now for weather thanks to the discovery of the infamous birth defect in one of the reindeers in 1939. There was also the time in 1966 where Santa helped Batman out of a jam all while keeping regular status report meetings with his team back at the North Pole. In more recent times, Santa Claus had to work out a wrestling dilemma for the World Wrestling Federation in 2006. The man is just everywhere!
However, the secret documents that were smuggled out and made into the movies "The Santa Clause" have given us the greatest insight into the risk mitigation strategies. First, if the actual Santa gets hurt or is in an accident and can't continue his duties, then someone else just puts on the suit and the risk has been mitigated. Of course, we find out that the lucky person who enters into the clause must also obtain a wife by next Christmas. That nearly caused the demise of the 2002 Christmas project.
Think about the scope creep that Santa has to deal with as well. First about 1.4 billion new children are born every year. That is quite a few new names and toys to have to estimate. Also, there is the checking of good versus bad that has to be worked out. I can tell you by experience that some kids can make a comeback! New technologies are being developed every day as well and it is harder and harder to keep the attention of our youth. What used to be wooded toys are now Wii's and Xbox's. Things move, make noise, and even appear to think nowadays. The cost of upgrading the workshop every year alone is staggering.
The teams change, the circumstances change, toys change, and yet year after year, the project date is made. There are over 800 appearances of Santa in the documented tales of his exploits and issue resolution practices in the ancient texts (again movies and TV!). Each and every time, Santa and his team find a way to deliver the project on time. For that, he is one of my top 5 mythical project managers of all time. Let the debate rage on for the other 4 slots! Who do you think and why?
Sunday, December 5, 2010
Wednesday, December 1, 2010
Why does the team need to see the schedule?
As part of my continuing series of addressing questions posed in my webinar, the next question to address asks:
"Do you have any suggestions for how to help your team of resources (who are untrained in PM concepts) understand what they are seeing in the schedule?"
I get this question quite a bit. In my opinion, I choose to not send the schedule to my team. I think I just heard the collective gasp. Before I get into what I do, let's discuss why I don't. When I am challenged on this thought in my speeches, I always ask, "What do you think happens when you send the full project plan?" Some of you out there may think that as soon as the resource gets the plan, they open it, print it, find their name and tasks, and study it to make sure they are ready to go. Although there are a few team members out there that might do this, the norm is to not even open the file. Most resources simply wait for the status meeting or for the e-mail to come to tell them to get started on their tasks.
So does it make sense to train all of the team members on how to read a project schedule? Also, what type of schedule? Several project managers write linearly based project schedules, meaning that their schedules go from Task 1 to Task 2 in the order in which they are to be performed. These schedules are against project theory as well. True project schedules should be written from WBS's and network diagrams. If this is the case, then many of the schedules are even more difficult to read because the tasks are grouped by deliverable and may increase the complexity of the predecessors. So what do I suggest? To-do lists.
I send each team member a report of their tasks. It is a simple report that shows the task name, start date, finish date, their estimate, and the actual hours that have been reported. It is sorted by start date and I show all of their tasks for the project. This tells them what they are really interested in, what do I need to do and when do I need to have it done?
Some people object asking, "What about the predecessors? Don't the resources need to see what needs to complete before they can get started?" My general answer is no. Most of the time, the predecessors came from the resource during the WBS/Network Diagramming session anyway. They already know what needs to complete before they can get started.
This approach has been very successful for me. It is simple, effective, and keeps team members focused on what they are supposed to do. I have also written Visual Basic code that automates the creation of Excel spreadsheets as task lists from Project. Another approach is to use the Reports->Assignments->To-Do List report that comes standard with Microsoft Project.
Whatever the format, just make sure that what the team member receives isn't information overload. This will allow you to communicate more effectively with each team member. It also allows you to manage risk and risk dates more efficiently by not revealing all of the dates to all of the resources. This isn't a shady practice or something you are trying to hide. It is simply your information to manage.
At least that is my opinion, please feel free to share yours.
Until next time,
Rick
"Do you have any suggestions for how to help your team of resources (who are untrained in PM concepts) understand what they are seeing in the schedule?"
I get this question quite a bit. In my opinion, I choose to not send the schedule to my team. I think I just heard the collective gasp. Before I get into what I do, let's discuss why I don't. When I am challenged on this thought in my speeches, I always ask, "What do you think happens when you send the full project plan?" Some of you out there may think that as soon as the resource gets the plan, they open it, print it, find their name and tasks, and study it to make sure they are ready to go. Although there are a few team members out there that might do this, the norm is to not even open the file. Most resources simply wait for the status meeting or for the e-mail to come to tell them to get started on their tasks.
So does it make sense to train all of the team members on how to read a project schedule? Also, what type of schedule? Several project managers write linearly based project schedules, meaning that their schedules go from Task 1 to Task 2 in the order in which they are to be performed. These schedules are against project theory as well. True project schedules should be written from WBS's and network diagrams. If this is the case, then many of the schedules are even more difficult to read because the tasks are grouped by deliverable and may increase the complexity of the predecessors. So what do I suggest? To-do lists.
I send each team member a report of their tasks. It is a simple report that shows the task name, start date, finish date, their estimate, and the actual hours that have been reported. It is sorted by start date and I show all of their tasks for the project. This tells them what they are really interested in, what do I need to do and when do I need to have it done?
Some people object asking, "What about the predecessors? Don't the resources need to see what needs to complete before they can get started?" My general answer is no. Most of the time, the predecessors came from the resource during the WBS/Network Diagramming session anyway. They already know what needs to complete before they can get started.
This approach has been very successful for me. It is simple, effective, and keeps team members focused on what they are supposed to do. I have also written Visual Basic code that automates the creation of Excel spreadsheets as task lists from Project. Another approach is to use the Reports->Assignments->To-Do List report that comes standard with Microsoft Project.
Whatever the format, just make sure that what the team member receives isn't information overload. This will allow you to communicate more effectively with each team member. It also allows you to manage risk and risk dates more efficiently by not revealing all of the dates to all of the resources. This isn't a shady practice or something you are trying to hide. It is simply your information to manage.
At least that is my opinion, please feel free to share yours.
Until next time,
Rick
Subscribe to:
Posts (Atom)