Monday, March 14, 2011
The Resource WAR
Project managers are often faced with limited resources and tight time frames. They are also on the hook for the project success or failure. This often means the covertly degrading of quality to slam in the project just to satisfy the deadlines. However, it is difficult for most project managers to articulate their needs for resources. Therefore, I have come up with an anagram for you to remember how to phrase the discussion to your sponsors to give them options for project deadlines.
If you have ever heard me speak, I often state that the best mindset for a project manager is the one that never says no. I say, "I can absolutely do that, here is what I need." I also teach to ask either/or questions instead of yes/no. So this brings me to the resource WAR:
W - WAIT - We can wait for the resources to become available.
A - AUGMENT or ACQUIRE - We can go hire consultants, a vendor, or get some contractors to do the work
R - REDIRECT - We can redirect the resources from another project to this one.
For every project that is resource constrained, those are your options. The key is to get the data for each of the options so that you can present it to the sponsor appropriately. For example:
W - Find out when the resources will be available. For this example, we will assume October of this year.
A - Find out the cost of the consultant or contractor.
R - Find out which projects the resources are working on.
Once you have the data, it is time to present what you have learned to the sponsor:
PM: Mr. or Ms. Sponsor, in order to deliver the timeframe that you have requested, I will need three more resources or the date could slide to December of this year.
Sponsor: December? We need this to be done by July!
PM: The resources that we need are not available until October. I did find out that we could bring in a consultant for $XX.
Sponsor: We do not have additional budget.
PM: What about diverting the resources from project XX to this one?
Sponsor: We can't stop that project.
PM: It seems our options are to wait until December, hire the consultant, or redirect the resources. What would you like to do?
That may seem over-simplistic, but in reality, what are the other options? Get ready for the resource WAR. Get the data and present it to your sponsors. Good luck out there!
Rick
Thursday, February 17, 2011
Be Careful What You Ask For!
Wow....what a week! I have been honored to work with a phenomenal organization to architect and develop a solution that can revolutionize an industry. This project blends project management, business process re-engineering, and solution design. It is a once in a lifetime type of project and the immediate team that I am working with is truly amazing. We were paid one of the nicest compliments that I have ever received from a client. This client had been working on the design of a solution and trying to find technology to deliver it for over two years. He said to me last night, "Where we are now is where we had hoped to be 12-14 months ago. However, having you guys on board made it worth the wait." That was just one of the many compliments delivered to us this week by one of the most amazing clients. I have never worked with a client that embraced and appreciated hard work as much as this one. We heard from the top of the organization, the senior leadership, the project manager, the business liaison, the IT sponsor and everywhere in between compliments as nice as that one.....as I said in the beginning...wow...what a week!
Early on in my career, I was called in to rescue a project that was one year past due and one million dollars over budget. The goal of the project was to reduce the entry of the items by the employees in the field from 5 minutes per item to 3 minutes per item. We spent another year developing this system that was originally estimated to take 6 months. I begged to meet with users in the field and gain their input in the design of the system. Each time, my request was denied. When we finally debuted the system just slightly two years overdue, the field users hated it. It now took them up to 15 minutes per item. We had increased their time instead of decreasing their time. The managers all thought they knew best and made all of the decisions during requirements and design. They were wrong. The end result was we lost the customer, they lost 2.5 years and 3 million dollars, and they had to start all over by throwing the system away and starting from scratch. Learning from that mistake, we had asked for user involvement in this current system we are developing. This leads me to the title of this blog post....be careful what you ask for!
This week was the culmination of 16 months of requirements and 5 months of heavy development with 6 separate incremental demonstrations of the functionality. We had a select group of individuals representing each of the roles in the system come in for the first true unveiling of the design. While the system overall was a hit, we missed a core element of the system in a big way. All of the requirements, all of the discussions, and all of the design sessions....and we missed a core element. At first, it was devastating. It was scary. What did it really mean? Luckily, it wasn't the first rodeo for me or the client. We were prepared to have something go wrong, but we were all honestly surprised how far we missed the core element. By the end of the session, we had a new design and a new approach hammered out and on the way to the core decision makers for their approval.
The moral of the story is you have to get to the users. You have to get the true input of the people that are the ones that are going to use the system. It does not matter how much expertise you have in the room, how good the developers are, or how long you spent doing requirements. If you do not have the core users giving you input on how the systems should function, your chances of success are reduced exponentially. At the same time, you must be careful what you ask for. When you do solicit feedback, make sure it is early enough in the process that you can make the appropriate adjustments. If we had this session 3-4 weeks later, I think it would have been detrimental to the project.
So the project management tip for this week, make sure you are getting users input. Make sure that you do it early enough in the project where the feedback can be applied to the project without many changes. Don't be afraid to ask....just be careful!
Until next time!
Rick
Early on in my career, I was called in to rescue a project that was one year past due and one million dollars over budget. The goal of the project was to reduce the entry of the items by the employees in the field from 5 minutes per item to 3 minutes per item. We spent another year developing this system that was originally estimated to take 6 months. I begged to meet with users in the field and gain their input in the design of the system. Each time, my request was denied. When we finally debuted the system just slightly two years overdue, the field users hated it. It now took them up to 15 minutes per item. We had increased their time instead of decreasing their time. The managers all thought they knew best and made all of the decisions during requirements and design. They were wrong. The end result was we lost the customer, they lost 2.5 years and 3 million dollars, and they had to start all over by throwing the system away and starting from scratch. Learning from that mistake, we had asked for user involvement in this current system we are developing. This leads me to the title of this blog post....be careful what you ask for!
This week was the culmination of 16 months of requirements and 5 months of heavy development with 6 separate incremental demonstrations of the functionality. We had a select group of individuals representing each of the roles in the system come in for the first true unveiling of the design. While the system overall was a hit, we missed a core element of the system in a big way. All of the requirements, all of the discussions, and all of the design sessions....and we missed a core element. At first, it was devastating. It was scary. What did it really mean? Luckily, it wasn't the first rodeo for me or the client. We were prepared to have something go wrong, but we were all honestly surprised how far we missed the core element. By the end of the session, we had a new design and a new approach hammered out and on the way to the core decision makers for their approval.
The moral of the story is you have to get to the users. You have to get the true input of the people that are the ones that are going to use the system. It does not matter how much expertise you have in the room, how good the developers are, or how long you spent doing requirements. If you do not have the core users giving you input on how the systems should function, your chances of success are reduced exponentially. At the same time, you must be careful what you ask for. When you do solicit feedback, make sure it is early enough in the process that you can make the appropriate adjustments. If we had this session 3-4 weeks later, I think it would have been detrimental to the project.
So the project management tip for this week, make sure you are getting users input. Make sure that you do it early enough in the project where the feedback can be applied to the project without many changes. Don't be afraid to ask....just be careful!
Until next time!
Rick
Thursday, February 3, 2011
Time for a New Set of Goals!
Happy Anniversary! I am proud and blessed to announce that R2 Consulting has turned 2 today. I can't believe it has been two years already. What an incredible journey this has been. The people that we have had a chance to work with, the solutions that we have been able to craft, and the ability to create an appropriate work/life balance have surpassed all expectations. We exceeded our first year revenue goals by over 10 % and grew an additional 5% over the next year. While 5% is modest growth, profitability grew by 61% year over year. We have also just concluded our largest revenue month ever. We created this little upstart in one of the most challenging economic times in our Nation's history and have been blessed to continue to do what we love while being able to support our families.
My VP of Sales, partner, and great friend Greg Huffman shared a story with me this morning on the 2 year anniversary. He had dinner last night with an associate of ours who told him the story of how he had met me. In 2005, I was a senior project manager for CA and was assigned to the Clarity implementation at a retail company in Jackson, MS. We were utilizing a partner company to do the implementation of the system. As I try to do with all of my partners and associates, I took the two gentlemen from this organization to dinner to become acquainted with them. Generally at these dinners, we tell stories of experience and past projects and begin to build a relationship with each other. At this particular dinner, I was asked what my career aspirations were. I had some ideas that were just brewing in my head at that time and listed my goals:
1) I wanted to write a book. (I have 3 on the market now)
2) I wanted to build a speaking career and seminar business around the book. (I speak for an average of two organizations or events per week)
3) I wanted to eventually own my firm. (R2 Consulting)
4) I wanted to consult in many different industries and inspire organizations to look at project managers as a strategic resource. (Our client and industry list continues to grow)
5) I wanted to travel the world with my family. (We go overseas at least twice per year. Once for vacation and at least once for a speaking engagement)
Those were my long term goals. When I woke up this morning, I had an e-mail from Greg wishing me a happy anniversary. He also said that our associate had relayed the conversation and was happy to see that I had achieved all that I said that I would. That made me pause for a moment. I have achieved what I had set out to do. Sometimes, we get so busy in our day to day routines that we often do not take a step back and reflect on where we have been, where we are, and where we are heading. I was blown away by the story. I can't believe that he remembered what I had said that evening. Now thinking back to what I had listed, those were items that I had wanted to accomplish over the next 10-15 years. I have been blessed to be surrounded with such a phenomenal group of friends, business associates, and family to help me achieve these goals so quickly. So it is time to set the next set of goals. Here goes:
1) Build a proven system that promotes project management and project managers as strategic resources that revolutionize the way organizations operate.
2) Create a motivational seminar series that teaches and empowers individuals and organizations to harness the power of change and improve their lives and communities.
3) Franchise the seminar series and create a worldwide audience.
4) Expand R2 Consulting to become the premiere resource for project management technology and development.
5) Spend more time fulfilling my roles for my family (Father, Husband)
There it is. Exposed for the world to see (or at least the 20 of you who actually read this post). Let's pray that the next 5 years grow like the last 5!
Finally tonight I wanted to touch on one other topic. On a post last April, I talked about why I like the small, family-based company feel (http://www.pmthatworks.com/2010/04/beyond-id-number-is-person.html). I was heartbroken to hear the shocking layoffs of two of my friends. One had been with a company for 16 years. She just recently had her second child and upon returning from maternity leave, she found out that her job was being outsourced to India. My other friend was put in a position a few years ago with no training and little chance for success. He persevered and was achieving his sales goals for the company. Furthermore, he was about to close a very lucrative deal that he had put quite a lot of effort towards. Two weeks before the signature of the deal, he was laid off. The Department of Labor talks about how transient the workforce is these days. They estimate that an average person will have five jobs before the age of 30. We also are seeing statistics of average length of employment at a company is two years. For the young mother of two, 16 years of loyalty was paid off by giving her job to a cheaper resource. The message continues to be sent that profit is more important than loyalty and service. Where has common sense gone? Where has loyalty gone? I remember I was almost removed from a company because I had exceeded my goals and it would have been more of a cost savings to the company to not pay me my incentive. They had made the decision to keep the person who was not performing as well. If I had not closed a big deal when I had, then they would have gone through with it.
I pray for my friends and for all of you out there who may find yourself in this position. Keep your head up. Maybe it is time for you to find your passion and pursue a career that gives you the freedom to do what you want and the satisfaction of doing it your way. Maybe it is time for you to set some new goals......
Until next time!
Rick
Monday, January 31, 2011
#3 and Feeling Good!
It has been a couple of weeks since my last post. No, I am not breaking my New Year's resolution, things have just been quite busy and the blessings continue to come! Here are several updates of what has been happening:
1) We received a message last night that this little old blog has been ranked #3 in a new listing of the Top 25 Blogs You Aren't Reading Yet. The two in front of this one are collaborative efforts, so we can say we are the #1 individually run (stretch much?). The list was published by Mr. Manager. You can read the article here:
http://mastersinprojectmanagement.org/25-best-project-management-blogs-you-arent-reading-yet.html#3
I have read through some of the other blogs listed and it is a great compilation of new project management blogs. I am quite honored!
2) I was interviewed recently by PM411.org for their podcast. This is the 67th podcast that they have created. You can hear the podcast here:
http://pm411.org/2011/01/14/podcast-episode-067-stop-playing-games/
Also, check out some of the other podcasts that they have. The content is fantastic!
3) I just finished working with the RMC Project Management team to create the audio book and an e-learning course based on the Stop Playing Games! book. I truly enjoy spending time with the RMC team. They always are so professional, down-to-earth, and driven for excellence. Laurie, Erica, Tim, Eric, Whitney, Jason, and a host of others are so much fun to be around and they make me look so much better than I really am!
Other than all of that, not much has been going on ;) Later this week I will restart the answering of questions that have been posed in the various webinars. I hope this message finds you well.
Passionately forging in to 2011,
Rick
Wednesday, January 5, 2011
Value of a Resource Loaded Schedule
Here is the next question in my continuing series of answering questions posed to me through the various webinars.
How do you get the senior members of the organization to realize the importance of a resource loaded schedule?
The Setup
I think the only way to bring the visibility to the senior executives is to be consistent with all of the schedules and then roll them up to view a true view of capacity. For instance, say that you are running 4 projects right now. Make sure that all of your schedules are resource loaded and appropriate. If they are not setup appropriately, read some of my other blog posts or either of my books to learn how to setup the plans. Once the plans are setup, then you need to roll up an aggregate view of the demand for the resources. If you have Project Server, Clarity, or any of these types of Enterprise tools, then learn how to do it there. If you do not have any of those tools, then use the "Resource Usage" view of your project plan to look at a monthly view of the total demand hours in your plans and plot those in a spreadsheet. You will end up with a chart that will show how busy the resources really are. Now add their "Other Work" such as admin time and operational support time. This gives you the total view of the demand of the resources.
The DeliveryNow that you have all of the data, when an executive asks for a new project or to accelerate a different one, you present them with the options that they have in an assumptive manner. You could say, "We would be happy to take on this project, how would you like to handle it? Should we hire a consultant or are you alright with waiting until October?" Of course, the executives are going to want to know why they can't have it right now. This is where you present them the aggregated view of the resources. If your company is like most, then your resources are maxed out. When you show this data to the executives, they will try to pick it apart. This is when you show them the resource loaded schedule, essentially proving your data. During the entire encounter, you need to maintain a positive outlook that you are happy to do anything and are willing to, you just need a decision as to what direction to take. Force the tough decision back to the executive.
The AftermathIt takes a few times for this to work, but eventually the executives will begin to accept the data. It is up to you to keep the data updated and relevant. As a side note, if you use a resource loaded schedule to delay a project start date or extend a project end date, then you will have no problems ever getting estimates from those resources again! I have worked with many executives in this capacity. It most cases, he/she will start to see the data for themselves and will begin to make the decisions. Being on both sides of the issue, I have often seen project managers tell me that a date or objective is impossible. However, when I challenge them, there is no substance to back up the claim. Having resource loaded schedules and understanding their impact on resource capacity can help make incredible strides in organizations.
TipSeveral companies ask me regularly to help them balance capacity and demand. My greatest tip is to not try to do the whole company at once. Pick one division (maybe the PMO itself) and balance their capacity and demand as a pilot. This is a relatively low level of effort to begin to have some of the conversations. I have a blog post titled "What About My Capacity?" that gives you a quick formula to ascertain the capacity of a PMO. Once the data is collected and the value of the data is realized, then expand it to a larger group.
Hoping you are finding your life's passion,
Rick
Sunday, December 5, 2010
One of the top 5 PM's of all time: Santa Claus
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?
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?
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)