Project Manager At A Large Financial Services Company
Job Title: Project Manager
Type of Company: Financial Services firm in Boston MA
Education: B.A. in Liberal Studies, New York University
Previous Experience: Consultant at Software Company
Job Tasks: My job as a project manager means that I need to influence a large number of people to work on my project without having them report in to me. My projects are software development projects, so that means I work with programmers, but also people that write software requirements (analysts), people who test the software before we install it (Quality Assurance engineers), people who represent the business side of the house, as well as sometimes customers.
The first thing I do is put together a project plan, which is a timeline for what activities we're going to do first, second, third, etc. Most projects I work on take anywhere between nine months and two years, but typically project managers when they start out work on smaller projects that tend to take six to nine months.
Since I work for a company that is large (30,000+ employees), there are many applications that are in use. And so my projects in particular are also very large and can include over one hundred applications that need to have a change made, all at the same time. So it's a major coordination effort.
A typical day for me is mostly conference calls and email, because we have people working on the project that are in five or six different locations in the U.S., and also India and Ireland. Time zones become tricky at that point.
A software development project is broken out into phases. The first phase is writing requirements, which the analyst will do, along with business folks. We write what's called a Requirements Document. Then the programmers get involved to design the software changes, and then write the code.
There are three levels of testing -- first the programmers test their code to make sure it works, then the QA engineers try to break it. They log a software incident or defect and the programmers then go back and fix the code. Then once all those defects are corrected, then the users are asked to test the software to make sure it does what they are expecting. Then finally we install the software onto the mainframe boxes (large computers) or servers, or client workstations (desktop computers) if applicable.
My day often involves dealing with problems that have occurred that I have to help fix. For example, if a developer doesn't have time to work on my project because he/she is busy on another project, then I need to work with their manager to either get another person, or if that's not possible, then I negotiate with the business to change the end date of the project. Or sometimes I'll suggest that we hire temporary worker to get the work done so we don't miss our dates.
Best and Worst Parts of the Job: The best part of my job is solving problems on a daily basis, and knowing that I'm moving my project forward. Since most people are working on multiple projects (including me often times), I am the one person responsible for making sure that my project gets done. The more problems I solve over the years, the better I get at it, and so the more effective I become.
The worst part of my job is giving bad news, which happens more than I'd like. Having to tell my project sponsor that a project is going to cost more money than I originally thought is always tough. Even if you have a good reason. And this is because the project has an ROI (return on investment). So if we spend $10,000 on a project for example, but we expect to increase revenue by $2000/month once we install the software, then it's going to take five months to break even (i.e. make back our investment), and then after that it's pure profit. But if the project ends up costing more than $10,000, let's say $14,000, then that's an extra two months to break even. In this example, it's worth it to still do the project. But sometimes the increase makes the project less worth it to do financially. And if we're half way through the project, and we've already spent half the money, then it's a difficult decision. Do we cancel the project and spend the money on a different project that has a better ROI? Do we keep going? Often times that's when we start cutting requirements. For example, if a project has 100 requirements, but 25 of them are 'nice to haves', it's possible to cut the cost of the project mid-stream but cutting out those 25 requirements. Our users always hate when we do it, but if it means that the return on investment makes more sense, then we have to help make the hard decisions to do the right thing for the firm.
Job Tips: To be a project manager for software projects, I think it's important to get a degree in Information Systems, or something similar, and make sure that you work as a programmer at least partially, for a few years. It will help you understand how the programmer thinks, and help you use the same words that they use. The more roles that you can fill yourself first before becoming a project manager, the better. I've been an analyst, a programmer, and a QA engineer and so I have first hand experience understanding what the people on my projects do every day. But I haven't filled every role, as that's not possible, especially in a big company. But the more I fill the better I can run projects that involve working with all these people.
Additional Thoughts: The most important qualities for success is organization, writing skills, ability to verbally communicate succinctly what you need to be accomplished, and influencing skills, because the people you rely on for your success don't work for you - they are your colleagues.