No, not a "new job" - a new "Project". No - it's NOT the same....

When friends and family ask me what I do - or what I am and I tell them, it is clear that some do not really understand the nature of the work. Oh, they understand projects - and most have worked on a project or two in their careers, but as a professional (and it is a profession that one learns, becomes skilled at and constantly seeks to improve) not many people really understand the nature of the work. Hopefully, after you read this, it will be somewhat more clear. I say somewhat because it can take years to completely understand and be comfortable with the concepts.

I am a Technology Project Manager. I manage large scale software implementation projects. That is to say, if your IT Department at work is putting in a new accounting package or sales automation tool or some expensive custom development system, I might be the Project Manager for that project. I have been doing this for a pretty long time - about 16 years overall and in that time, I have managed, hundreds of projects.  Budgets for those projects - which the Project Manager is responsible for managing and making sure to stay carefully within those bounds can range from thousands of dollars to multi-millions of dollars.

Projects have a life all their own. It's called a 'lifecycle' actually or 'Software Development LifeCycle" (SDLC). In the business or practice of Project Management the lifecycle has defined phases along the journey from beginning to end.

First, to start a project, someone has to have an idea or a problem that needs a solution; that is 'Initiation'. Then, all the details about the project are discussed and captured; that is 'Discovery'. After the details are captured, all the features and functions the users want or need from the system are documented; that is 'Requirements'. Once the needs are written, the system is sketched out or blue printed; that is 'Design'. Just like a house, once the design or blueprint exists, the building can start; that is 'Development'. After building (and hopefully during building) the system needs to be checked against what the users said they wanted; that is 'Testing'. The users will need to be taught how to use the new tool; that is 'Training'. Following all of the other steps that have been completed, the system is ready to be put into use; that is 'Deployment' and then, when all the loose ends are tied up, the project is finished and measuring how well it was done can happen.

Now, you will hear all kinds of different terms, acronyms, methods or approaches to manage projects.   But basically, they are all variations on the theme above because at the most basic level, all those things have to happen so that you can plan, measure and execute projects. Even though we have metrics to measure them, no two projects are ever exactly the same. Sometimes it is a different team of people or different types or versions of software or hardware, but in all the years I've done this, no two projects have ever been exactly alike and I have never done a project where I haven't learned something new.

Sometimes, there are new systems and from soup to nuts (we say 'cradle to grave') the project can last over a year. Sometimes, they are simple upgrades to new versions of software and may only take 2 - 3 months. The typical project I manage lasts about 6 - 12 months. Depending on the needs of the organization and how in depth they want me to work with the project, I may manage more than one project at a time - that group of projects is called a portfolio. It is hard when the portfolio gets to be more than about 6 - 8 projects because it is hard to know every issue and every deadline or due date on more than 8 projects. I have had up to 11 projects at one time, but I wasn't a very nice person to be around then.

Project Managers deal with the timelines, budgets, task assignments and due dates of all people and resources pertaining to the projects in their care. Once a project is completed, it is 'put to bed' and the system goes into what is referred to as 'maintenance mode'. That is to say, developers and technicians may still need to do some work on the system, but the bulk of the work is done and the Project Manager is repurposed (put on a new project) or cut loose - moves on to another group or company to manage a new adventure.

There are some pros and cons to being an Implementation Project Manager. It is exciting and fast paced, you are always on the leading edge - some say 'bleeding edge' of new technologies and you get to work with a lot of different people in lots of different places - all around the world. Those are pro's. On the flip side, it can be stressful - especially when things aren't done on time because something broke or someone had an unexpected issue or, well - any number of obstacles crop up. It can be frustrating because as someone bringing in a new tool, some of the people using the old tool don't want to change. People can become obstacles for lots of reasons. Maybe they are scared their job will go away. Maybe they are scared they won't be able to learn the new technology or that the company will hire someone younger who can do the job cheaper. Project Management can also be uncertain at times - projects get canceled or defunded; projects finish and then the job can be ended. You may be out looking for your next "new gig" at any time.

There are ways to manage the risk associated with projects ending abruptly or projects having the funding pulled. That is typically the manner of company the Project Manager (PM) works with or for. As a PM, you can be hired by the company doing the project. You work for company "A" they pay you and you have benefits and perks just like any other traditional employee. This is typically called 'Direct'.

You can work for a company - "A" whose business is selling technical services to other companies "B" and when the services are sold, you do the project for "B" with a team from both "A" and "B". When the project is done, "B's" salespeople have sold other projects to other businesses and you start another project or there may be a small lag before the project starts, but you still work for "B" and are temporarily on the 'bench', but still a full employee being paid and getting benefits. This is typically called 'Consulting'.

Another employment option has a few more variations. You work through an agency "A" and they hunt up opportunities to place you on a project - company "B". You can either be paid via W-2 (taxes taken out) or 1099 (you pay your own taxes and you are company "C") but, you don't get typical benefits like holidays or vacation or sick time. You might get healthcare or insurance if you need it, but the rates may not be great. You can get more money working in this manner, but some people are not comfortable because it can seem 'temporary'. (Although, in today's economic and work environment, it is no more 'temporary' than any other position - as we see now- anyone is expendable.) This is typically called 'Contracting'.

I have been employed in all of the ways described; some are nicer than others. Some can be much more lucrative and sometimes, that is what you may need. But, as a professional PM, you have to be flexible and open to accepting whatever type of employment method is available in the economic cycle and that, really is the driver.

For instance, during the 90's, everyone wanted to hire PM's direct so that you worked for them and they could use you on a number of projects because IT was new and projects were quite literally coming out of the walls. Running up to Y2K, consulting was huge because the big consulting firms - grown out of the big accounting houses - could charge huge hourly rates for PM's. In 1998 and 1999, it was not uncommon for good, experienced PM's to have rates (charged by the consulting house, not earned by the PM) anywhere from $300 - $500/hour. After the Dotcom bubble burst, no one really wanted to pay PM's. Companies tried to have developers be both programmers and PM's, but that was an epic fail - and then PM"s were desperately needed to fix all the disasters caused by letting developers (geeks) do whatever they wanted with no one steering the ship. This brought about a growth in Contract positions because there were so many projects that needed PM's that changing jobs that often was simply not great on a resume until people really grew to understand Project Management and the professional Project Manager.

Salary is driven by the manner of work, the years of experience and the technology of the project. It is really a wide and varied field. New PM's might come onto their first project under a veteran PM and be earning an entry level salary that can range from $35K - $55K. Certified PM's can range all over the place because a certificate means more with years of experience. Those ranges can go from $50K - $90K depending. Senior level PM's with years of success under their belts can command top salaries, or top hourly rates, depending on what they negotiate and the field is very open to negotiations. PM's at the top of their game can expect salaries starting around $100K on up or hourly rates from $50/hour to $100/hour or sometimes more depending on the details of the project. However, to whom much is given, much is required. Being a PM is not a 40 hour/week job. There is travel, overnight "go live's", late night emergencies, head aches and juggling of family to deal with too. Those "top" salaries required experience and dedication that is only achieved through paying a lot of dues over the years.

Because of this changeable nature of projects, project employment and by extension, Project Management, some may say "well, that doesn't seem like very reliable work". If you were the type of person who was looking to be in one place for your entire 40 year career, that would probably be somewhat true. But, there are always going to be new technologies and new businesses that need new systems or businesses that need to change or tweak systems.

So, if you are a good Project Manager, there will always be a need for what you do thereby ensuring that you will always find a project that needs you. Similarly, if you are a good PM, you wouldn't want to stay in one place for 40 years because you are, in fact, an agent of change and the one constant about change is that it is always happening. I for one am glad - because I like being a PM with all the change and challenges - it's just who I am.