Cloud computing has become one of the more interesting trends in the technical world in the last year or so. But it is not easy to see through the fog surrounding this latest buzzword. It’s worthwhile for a project manager to understand this trend and to think about where it might take us.
The term cloud computing came from the world of networking, where a diagram of a wide-area network would often show a large cloud in the middle that was meant to represent some mixture of the Internet and private links. The idea was that the communications from various servers and workstations went into the cloud and the cloud took care of routing the communications to the correct point. The cloud was generally conceived to be managed by the ISP or telecom company.
Recently, virtualization has allowed any server to be easily split into many small servers that could be resized and brought up and down, independent of the underlying hardware. A hosting provider could allow a customer to manage their server resources in a more flexible manner. A virtual server could be made available somewhere on the Internet and so could be thought of as a “cloud computer”.
Curiously, the organizations that have begun to make a serious impact on cloud computing have not been ISPs, telecoms or hosting providers. Instead, it has been a small group of large companies that already had very large infrastructures set up to manage their own businesses. We are talking here about Amazon, Google and Microsoft. Of the three, the Amazon offering is the most mature and I’ll focus on it as an example of how this all works.
Amazon’s offering is called simply Amazon Web Services – AWS. Its most basic components are Elastic Compute Cloud (EC2) and Simple Storage Service (S3). The EC2 service allows a user to set up virtual servers quickly and easily, paying only for the resources actually used. The S3 service allows users to store data – any kind of data – and access it from an EC2 server or anywhere within their own infrastructure.
This way of working can be very cost-effective for testing. A tech can bring up a virtual server, load software and data and be ready to test in a short period of time. When he is done testing, he can save the data to S3 (or on a server back in his own office) and drop the virtual server. He can do several days testing for just a few dollars. If he had to get a real server it could take weeks and cost hundreds of dollars or more.
Beyond testing, this kind of set-up can be a great help for a company who has a lot of peaks and valleys in their computing needs, such as retailers who get most of their sales in November-December. They can have a small virtual server most of the year and easily double or triple their capacity during the holiday sales season.
It probably makes less sense for a company with a steady, even usage pattern and little (or very predictable) growth to use this kind of service for production. This kind of company can plan, purchase, install and maintain servers and storage far enough in advance to meet demand and probably do it less expensively. But in today’s environment, there are fewer and fewer organizations who are in this predictable category.
From everything I have seen, Amazon is far in advance of anyone else in terms of their services, management, reliability and availability.
I started using Amazon S3 nearly a year ago almost by accident. I wanted an easy, cheap and secure way to store important files online for backup purposes.. There are several commercial offerings that charge upwards of $15 per month. With S3 and an inexpensive software component (Jungledisk - $10), I was up and running very quickly. The cost? About $1 per month!
As a project manager, if you have any flexibility in how your infrastructure is deployed, it would be worth your while to investigate cloud computing as an alternative. It could be a way for you to shave costs and time. It is not appropriate for every task (security policies may make it impossible). But if you have ever had to wait weeks for procurement to get you that test server, it can be a huge victory to get it done in a couple of hours for one-tenth the cost.
Keep an eye on this technology. The fog will clear and I predict sunny weather ahead.
Links:
http://aws.amazon.com
http://www.jungledisk.com
Sunday, June 14, 2009
Wednesday, May 20, 2009
A New Venture
I have spent many years now working for various organizations as an employee. There is nothing wrong with that – a well-managed group can accomplish a great deal and working as part of a large team can be very rewarding. But I, like many in America and elsewhere, have always had the dream of starting something on my own, my own company.
I have recently decided that now is the time for me to take on such a new challenge. I want to be able to use the things I have learned about systems, organizations, projects and people and put these together in a package that I can offer to others to help them achieve success.
To that end, I have formed Pinnacle Project Group (www.PinnacleProjectGroup.com). Our mission and goal will be to help create a better world through the application of superior IT project management. We will achieve this by ensuring that our client’s projects deliver real business value to their organizations.
I know that “a better world” is a lofty goal for a consultancy that currently consists of one person. But I believe strongly that we all should be striving to create a better world in whatever big or small way we can. If we are not doing so, we must perforce be allowing the world to get worse, if only by neglect. We can all make an impact – even if it is only in one small corner of the world.
I would invite you to think about your projects and the impact they have on the world around you. Will the project lead to something that improves conditions in the world? More than it harms? If not, consider whether this is a project that you want to be associated with.
In tough economic times it can be difficult to think beyond the welfare of yourself and your immediate family. But if you look over recent history, you can probably see that considering only self-interest is what got us into this mess.
I think you will not find it hard to consider the greater good in your actions. For some excellent guidance, have a look at the booklet The Way to Happiness”, which can be found at this link:
www.thewaytohappiness.org/about/resources-and-downloads/e-books.
I have spent many years now working for various organizations as an employee. There is nothing wrong with that – a well-managed group can accomplish a great deal and working as part of a large team can be very rewarding. But I, like many in America and elsewhere, have always had the dream of starting something on my own, my own company.
I have recently decided that now is the time for me to take on such a new challenge. I want to be able to use the things I have learned about systems, organizations, projects and people and put these together in a package that I can offer to others to help them achieve success.
To that end, I have formed Pinnacle Project Group (www.PinnacleProjectGroup.com). Our mission and goal will be to help create a better world through the application of superior IT project management. We will achieve this by ensuring that our client’s projects deliver real business value to their organizations.
I know that “a better world” is a lofty goal for a consultancy that currently consists of one person. But I believe strongly that we all should be striving to create a better world in whatever big or small way we can. If we are not doing so, we must perforce be allowing the world to get worse, if only by neglect. We can all make an impact – even if it is only in one small corner of the world.
I would invite you to think about your projects and the impact they have on the world around you. Will the project lead to something that improves conditions in the world? More than it harms? If not, consider whether this is a project that you want to be associated with.
In tough economic times it can be difficult to think beyond the welfare of yourself and your immediate family. But if you look over recent history, you can probably see that considering only self-interest is what got us into this mess.
I think you will not find it hard to consider the greater good in your actions. For some excellent guidance, have a look at the booklet The Way to Happiness”, which can be found at this link:
www.thewaytohappiness.org/about/resources-and-downloads/e-books.
Friday, May 8, 2009
Zap Some Life Into Your Service Oriented Architecture Project
If you are in any stage of a Service Oriented Architecture (SOA) project or if you just want to find out what SOA is really about, you would do very well to check out the information on the subject provided by www.zapthink.com.
It is not entirely clear to me at this point that SOA is the ultimate answer to everything wrong with the way we build computerized systems, but I do believe that it is an important step toward what should be our ultimate goal: highly reliable, integrated, efficient systems that can perform real work and provide real value to the Enterprise.
Zapthink is a consultancy that has been in the forefront of the SOA evolution. They are an independent, vendor-neutral voice, pointing out that SOA is an architectural concept, not a technology.
The large software vendors promote their packages and methodologies as a way to “buy SOA”. It is not surprising that most of these kinds of projects have not been able to show much in the way of business value. Installing a package and calling it SOA is akin to buying a refrigerator and calling it dinner – you might be able to make dinner with the help of a fridge, but you can also do it without the fridge and it just might be a better dinner if you just bring home the fresh ingredients and start cooking.
The dinner analogy is perhaps not the best, but the point is that SOA needs to be thought through carefully before laying down the money for any technology. You need to think about the kinds of services that will make sense for your business and how best to implement these services, given the mix of technology currently available or planned for the near future.
Have a look at Zapthink and decide for yourself. Their newsletter is free and definitely worth a read.
It is not entirely clear to me at this point that SOA is the ultimate answer to everything wrong with the way we build computerized systems, but I do believe that it is an important step toward what should be our ultimate goal: highly reliable, integrated, efficient systems that can perform real work and provide real value to the Enterprise.
Zapthink is a consultancy that has been in the forefront of the SOA evolution. They are an independent, vendor-neutral voice, pointing out that SOA is an architectural concept, not a technology.
The large software vendors promote their packages and methodologies as a way to “buy SOA”. It is not surprising that most of these kinds of projects have not been able to show much in the way of business value. Installing a package and calling it SOA is akin to buying a refrigerator and calling it dinner – you might be able to make dinner with the help of a fridge, but you can also do it without the fridge and it just might be a better dinner if you just bring home the fresh ingredients and start cooking.
The dinner analogy is perhaps not the best, but the point is that SOA needs to be thought through carefully before laying down the money for any technology. You need to think about the kinds of services that will make sense for your business and how best to implement these services, given the mix of technology currently available or planned for the near future.
Have a look at Zapthink and decide for yourself. Their newsletter is free and definitely worth a read.
Monday, May 4, 2009
Myths of Failed Projects
How many times have you heard frightening statistics on the number of IT projects that “fail”? It is common to hear numbers well above 50%. Does this match your experience in the real world or those projects you have heard about? In my experience, the percent of truly failed projects is much less then that.
The key to determining the real percentage is, of course, to define what is meant by “failure”. I do not know what criteria the various surveys or analysis use and I’m not going to attempt to refute any published studies. But at the start, I will define a successful project as follows:
A successful project is any that provide positive business value over the life of the product of the project.
By this measure, a project could be well over budget and behind schedule at the end of the project, but so long as a viable product is created that delivers positive business value in excess of the cost of the project, it could be deemed successful.
Should we toss out completely measures such as Earned value and Cost performance Index? No, these are valuable in tracking how well a project is proceeding according to plan. These measures, however, only address how well the project team did their planning, not necessarily the value the product of the project brings to the organization. The measurement of “on time and within budget” are subservient to the real statistics that should be tracked, which must be a measure of business value.
If you are a Project Manager, you could argue that it may take years to determine project success based on this definition. You would be right in some cases. But in many cases, it can be rather easy to determine success by the time of project close. For example, a project that replaces an aging, expensive system with a new system based on commodity hardware and software components can be shown to have a payback period within a few months or a year after the project is closed.
It is true that things can go wrong after a project is done and the team is long gone. Only the passage of time will ensure that you know exactly what the payback is and how rapidly it occurred. I know of few organizations that track projects over the necessary spans of time that would be required. That is unfortunate, but a reality, since managers tend not to care about how old projects performed, only how they will get the next one done on time.
Is it worthwhile tracking project performance in this manner? I would suggest that any project manager would be well advised to do this to the greatest extent possible. Track your projects for at least a year a after completion and see how they are performing.
A PM might argue that this metric is outside of his control. He could argue “it’s not my fault if the organization dropped the ball after the project closed”. That might well be true, but it is also important for you to understand why the product did not succeed, it that was the case. Update your lessons learned on the project with information that could be helpful for the next project.
If Project Managers can take a long view of project success, they have a much better chance of being perceived as skilled managers. If we can show that our projects did in fact deliver business value we can all get beyond these myths of so many failed projects.
The key to determining the real percentage is, of course, to define what is meant by “failure”. I do not know what criteria the various surveys or analysis use and I’m not going to attempt to refute any published studies. But at the start, I will define a successful project as follows:
A successful project is any that provide positive business value over the life of the product of the project.
By this measure, a project could be well over budget and behind schedule at the end of the project, but so long as a viable product is created that delivers positive business value in excess of the cost of the project, it could be deemed successful.
Should we toss out completely measures such as Earned value and Cost performance Index? No, these are valuable in tracking how well a project is proceeding according to plan. These measures, however, only address how well the project team did their planning, not necessarily the value the product of the project brings to the organization. The measurement of “on time and within budget” are subservient to the real statistics that should be tracked, which must be a measure of business value.
If you are a Project Manager, you could argue that it may take years to determine project success based on this definition. You would be right in some cases. But in many cases, it can be rather easy to determine success by the time of project close. For example, a project that replaces an aging, expensive system with a new system based on commodity hardware and software components can be shown to have a payback period within a few months or a year after the project is closed.
It is true that things can go wrong after a project is done and the team is long gone. Only the passage of time will ensure that you know exactly what the payback is and how rapidly it occurred. I know of few organizations that track projects over the necessary spans of time that would be required. That is unfortunate, but a reality, since managers tend not to care about how old projects performed, only how they will get the next one done on time.
Is it worthwhile tracking project performance in this manner? I would suggest that any project manager would be well advised to do this to the greatest extent possible. Track your projects for at least a year a after completion and see how they are performing.
A PM might argue that this metric is outside of his control. He could argue “it’s not my fault if the organization dropped the ball after the project closed”. That might well be true, but it is also important for you to understand why the product did not succeed, it that was the case. Update your lessons learned on the project with information that could be helpful for the next project.
If Project Managers can take a long view of project success, they have a much better chance of being perceived as skilled managers. If we can show that our projects did in fact deliver business value we can all get beyond these myths of so many failed projects.
Friday, February 27, 2009
The Completion of a Project and the Start of a New Chapter
Just recently I completed a major project – the third phase of a project that had extended over nearly four years all-told. The project involved implementing a data warehouse with a global scope, involving over 30 different countries and in excess of 50 million customer records.
I think it is fair to say the project was a major success. It consolidated several systems the company had been using, dramatically lowered costs, increased the business intelligence capabilities of the organization and was extremely well-received by the users. In all my years of doing project work, I have rarely seen a project achieve such positive results. This may sound like personal horn-blowing, but if you spoke to the key stakeholders, I think you would find that they would generally agree.
It is not that the project went completely smoothly and with no hiccups. The last phase in particular (converting an old mainframe-based system) was a tough one and it went several months longer than the original plan. There are many reasons for this, the primary one being underestimating the effort involved in converting some of the very technical and complex functions. But in the end the project delivered very positive business value. And delivering business value is what a project should be all about.
There were many lessons learned on this project. I’d like to focus on one aspect here that could be of help to other PMs. This is how to effectively close a project without leaving many loose ends.
In my experience, projects do not often close in a clean manner, with everything wrapped up and delivered and nothing left to tidy up. Often the projects seem to just go on forever in a sort of maintenance mode, with new issues arising week after week. On the other hand, sometimes the project is closed abruptly with software full of bugs and the users feeling that the product is incomplete.
There may be many ways to manage this. The closing process in the PMBOK is straightforward – you complete all the work assignments, release the resources, close any contracts, write up Lessons Learned and have a party. It seldom works out so cleanly.
There are two primary ways to ensure that all loose ends are tied up. They can also be used to compliment each other.
First, at the end of the project all outstanding issues are either closed or they are converted into open requests or tickets in the normal maintenance system.
The other way to manage this is to build a warranty period into the project, where some project resources are kept at least part-time to resolve any issues or bugs that arise. The project is formally close before the start of the warranty period and the warranty work is done under the auspices of the organizations normal maintenance process.
The warranty makes most sense when the product of the project is delivered to an outside organization, but it also can be used within an enterprise, especially when the product is delivered to another department or group.
But the key thing is – don’t leave loose ends! They will come back to haunt you.
I have made my best efforts to apply these principles to my recent projects. The effect has not been perfect, but it has had a positive impact.
============================================
As the title of this post implies, the end of my most recent project has also meant the opening of a new chapter in my career and life. I have left the organization where I had spent over 20 years. There were many reasons for my departure, but in essence the company and I both felt that it was time to part. They were and continue to be very gracious and generous.. I greatly appreciate their good will.
I am taking some time now to assess my future and to look over my options. I will be working to establish myself as an independent consultant, one who can assist in the management of any IT project and make those projects work better.
To see more about me and my background and competencies, see my Linkedin profile: http://www.linkedin.com/pub/8/648/258.
I think it is fair to say the project was a major success. It consolidated several systems the company had been using, dramatically lowered costs, increased the business intelligence capabilities of the organization and was extremely well-received by the users. In all my years of doing project work, I have rarely seen a project achieve such positive results. This may sound like personal horn-blowing, but if you spoke to the key stakeholders, I think you would find that they would generally agree.
It is not that the project went completely smoothly and with no hiccups. The last phase in particular (converting an old mainframe-based system) was a tough one and it went several months longer than the original plan. There are many reasons for this, the primary one being underestimating the effort involved in converting some of the very technical and complex functions. But in the end the project delivered very positive business value. And delivering business value is what a project should be all about.
There were many lessons learned on this project. I’d like to focus on one aspect here that could be of help to other PMs. This is how to effectively close a project without leaving many loose ends.
In my experience, projects do not often close in a clean manner, with everything wrapped up and delivered and nothing left to tidy up. Often the projects seem to just go on forever in a sort of maintenance mode, with new issues arising week after week. On the other hand, sometimes the project is closed abruptly with software full of bugs and the users feeling that the product is incomplete.
There may be many ways to manage this. The closing process in the PMBOK is straightforward – you complete all the work assignments, release the resources, close any contracts, write up Lessons Learned and have a party. It seldom works out so cleanly.
There are two primary ways to ensure that all loose ends are tied up. They can also be used to compliment each other.
First, at the end of the project all outstanding issues are either closed or they are converted into open requests or tickets in the normal maintenance system.
The other way to manage this is to build a warranty period into the project, where some project resources are kept at least part-time to resolve any issues or bugs that arise. The project is formally close before the start of the warranty period and the warranty work is done under the auspices of the organizations normal maintenance process.
The warranty makes most sense when the product of the project is delivered to an outside organization, but it also can be used within an enterprise, especially when the product is delivered to another department or group.
But the key thing is – don’t leave loose ends! They will come back to haunt you.
I have made my best efforts to apply these principles to my recent projects. The effect has not been perfect, but it has had a positive impact.
============================================
As the title of this post implies, the end of my most recent project has also meant the opening of a new chapter in my career and life. I have left the organization where I had spent over 20 years. There were many reasons for my departure, but in essence the company and I both felt that it was time to part. They were and continue to be very gracious and generous.. I greatly appreciate their good will.
I am taking some time now to assess my future and to look over my options. I will be working to establish myself as an independent consultant, one who can assist in the management of any IT project and make those projects work better.
To see more about me and my background and competencies, see my Linkedin profile: http://www.linkedin.com/pub/8/648/258.
Sunday, November 30, 2008
Does a PM Need To Be a Technical Expert?
My current project has been getting rather intense lately, which has not given me much time to post anything on this blog. But now I’m winding down from the Thanksgiving holiday and there seems to be a few spare minutes in the day.
I had been thinking recently about what makes an effective project manager. I’ve seen many named and de facto project managers over the years who have been assigned to manage technical projects. Most often the primary qualification is that they have technical experience that is directly related to the project. Sometimes these managers are successful and sometimes not. So is it the best strategy to appoint a PM with technical skills?
In the IT world, we are rather obsessed with technical knowledge and ability. The IT field has only been around in a serious way for about 40 years now. In the beginning, the IT people were scientists and would work on their machines in white lab coats. No one would dream of asking any of them if they had any idea about how to manage projects or people. The IT field has retained that scientific and technical bias to this day. A programmer or analyst with the best technical chops was very often elevated to Lead Analyst or even Project Manager based solely on his tech expertise. Sometimes it worked and sometimes it was a disaster.
The profession of project manager has grown up primarily in areas such as construction and engineering. Those fields realized that the ability to organize and manage projects and people was a skill in its own right and was perhaps even secondary in importance to technical knowledge. Those fields still tended to use technical experts as PMs, but technical expertise was not the only criteria.
In the 1960s, John Zachman, then with IBM, began to realize that the computer industry was in a crisis. Building robust, bug-free systems that met business needs and staying within budget seemed to be an impossible goal. Many projects failed and many more went vastly over budget. He looked over at industries that made things rather than software and observed that they seemed to be very successful – planes could fly, buildings went up and didn’t bust the budget, widgets got made and sold for a profit.
John studied some of these industries in detail and developed his Enterprise Architecture as a way to formalize all of the aspects of any organization and how they would have to work together to create a functioning Enterprise. His Zachman Enterprise Architecture Framework (http://www.zifa.com) focused on all the details required to plan and design systems that could run an Enterprise. He did not focus on project management, since that was not what he was looking for.
I believe Zachman’s assumption was that project management was a well-understood discipline and that it did not need to be covered explicitly in his framework, although many aspects of project management can be found in his matrix. Good project management would be essential to drive the implementation of this framework and the lack of this may explain why so few organizations have been able to successfully implement it.
Enterprise architecture and project management have distinct synergies and overlapping areas of application. Any architect needs to know how to manage projects and a PM working in IT needs to understand how to do architecture (or the PM needs to have a good architect on his team).
Both the architect and the PM need to be able to understand the technology they are working with. If they are not conversant with the tools and methods that are being employed on their projects they soon become snowed under with terms and concepts they do not understand. And they can become overly dependent on the technical members of their team.
The fact is however, that technical knowledge is easier to come by and more widely available than project management skills, especially in the IT arena. Many lead analysts and programmers finding themselves in the PM role have no idea how to plan and manage a project. They know how to put together the technical details, but projects under their lead are in fact not under their control at all. Very often their senior managers are in effect acting as project managers. This leads to frustration on both sides, as the technical leader feels he is not in control and the manager does not have the time for the day-to-day process of managing an ongoing project.
The ideal situation is a PM with the right mix of technical and project management knowledge and experience. But it is often difficult to find one individual who meets this criteria. I would urge any senior manager to ensure that their technical personnel get PM training and that when putting someone in charge of a critical project they look first to find a person with PM knowledge and experience and make the technical qualifications secondary. You can always find the right technical resources to help the PM where he might need it.
As for myself, as I’ve said before on this blog, I love the technical stuff. But I have realized that if I want my own projects to succeed, I have to understand more then just the technical aspects. I would recommend to anyone in IT to improve his or her project management skills as a priority. It will certainly pay off.
I had been thinking recently about what makes an effective project manager. I’ve seen many named and de facto project managers over the years who have been assigned to manage technical projects. Most often the primary qualification is that they have technical experience that is directly related to the project. Sometimes these managers are successful and sometimes not. So is it the best strategy to appoint a PM with technical skills?
In the IT world, we are rather obsessed with technical knowledge and ability. The IT field has only been around in a serious way for about 40 years now. In the beginning, the IT people were scientists and would work on their machines in white lab coats. No one would dream of asking any of them if they had any idea about how to manage projects or people. The IT field has retained that scientific and technical bias to this day. A programmer or analyst with the best technical chops was very often elevated to Lead Analyst or even Project Manager based solely on his tech expertise. Sometimes it worked and sometimes it was a disaster.
The profession of project manager has grown up primarily in areas such as construction and engineering. Those fields realized that the ability to organize and manage projects and people was a skill in its own right and was perhaps even secondary in importance to technical knowledge. Those fields still tended to use technical experts as PMs, but technical expertise was not the only criteria.
In the 1960s, John Zachman, then with IBM, began to realize that the computer industry was in a crisis. Building robust, bug-free systems that met business needs and staying within budget seemed to be an impossible goal. Many projects failed and many more went vastly over budget. He looked over at industries that made things rather than software and observed that they seemed to be very successful – planes could fly, buildings went up and didn’t bust the budget, widgets got made and sold for a profit.
John studied some of these industries in detail and developed his Enterprise Architecture as a way to formalize all of the aspects of any organization and how they would have to work together to create a functioning Enterprise. His Zachman Enterprise Architecture Framework (http://www.zifa.com) focused on all the details required to plan and design systems that could run an Enterprise. He did not focus on project management, since that was not what he was looking for.
I believe Zachman’s assumption was that project management was a well-understood discipline and that it did not need to be covered explicitly in his framework, although many aspects of project management can be found in his matrix. Good project management would be essential to drive the implementation of this framework and the lack of this may explain why so few organizations have been able to successfully implement it.
Enterprise architecture and project management have distinct synergies and overlapping areas of application. Any architect needs to know how to manage projects and a PM working in IT needs to understand how to do architecture (or the PM needs to have a good architect on his team).
Both the architect and the PM need to be able to understand the technology they are working with. If they are not conversant with the tools and methods that are being employed on their projects they soon become snowed under with terms and concepts they do not understand. And they can become overly dependent on the technical members of their team.
The fact is however, that technical knowledge is easier to come by and more widely available than project management skills, especially in the IT arena. Many lead analysts and programmers finding themselves in the PM role have no idea how to plan and manage a project. They know how to put together the technical details, but projects under their lead are in fact not under their control at all. Very often their senior managers are in effect acting as project managers. This leads to frustration on both sides, as the technical leader feels he is not in control and the manager does not have the time for the day-to-day process of managing an ongoing project.
The ideal situation is a PM with the right mix of technical and project management knowledge and experience. But it is often difficult to find one individual who meets this criteria. I would urge any senior manager to ensure that their technical personnel get PM training and that when putting someone in charge of a critical project they look first to find a person with PM knowledge and experience and make the technical qualifications secondary. You can always find the right technical resources to help the PM where he might need it.
As for myself, as I’ve said before on this blog, I love the technical stuff. But I have realized that if I want my own projects to succeed, I have to understand more then just the technical aspects. I would recommend to anyone in IT to improve his or her project management skills as a priority. It will certainly pay off.
Saturday, September 20, 2008
Two Good Books on Job Hunting
In my last post I talked about the challenges of working with a global team and some of the issues that arise from the practice of out-sourcing. While it is not directly on the subject, it might be helpful for some to know of a couple of good books on the subject of job hunting. And since nearly everyone will face a job change at some point, they are good resources for all of us.
The first book is “Ask the Headhunter: Reinventing the Interview to Win the Job” by Nick A. Corcodilos. This is an excellent look at how to break out of the old stereotypes of job hunting and interviewing and to focus on the things that will get you the job you want. The author’s web site is:
http://www.asktheheadhunter.com/
The other book is “What Color is Your Parachute” by Richard N. Bolles. This is probably the most popular book on job hunting ever written and for good reason. It has many good ideas and resources. His web site is:
http://www.jobhuntersbible.com/
The first book is “Ask the Headhunter: Reinventing the Interview to Win the Job” by Nick A. Corcodilos. This is an excellent look at how to break out of the old stereotypes of job hunting and interviewing and to focus on the things that will get you the job you want. The author’s web site is:
http://www.asktheheadhunter.com/
The other book is “What Color is Your Parachute” by Richard N. Bolles. This is probably the most popular book on job hunting ever written and for good reason. It has many good ideas and resources. His web site is:
http://www.jobhuntersbible.com/
Subscribe to:
Posts (Atom)