views:

161

answers:

7

I am a full-time Developer who aspires to be a great technical Project Manager.

What are the key steps that you think I need to go through to achieve that aspiration?

I am interested in professional qualifications (e.g. PRINCE2, etc.), training courses, personality traits, experiences, tips and techniques that would improve my chances of being the best I can be.

I would be interested in hearing if anybody has done this, and whether they are happy with their change from development or if they wished they had stuck to a development (and the reasons behind this decision).

A: 
    1) Pay attention to detail
    2) Do not micro-manage
    3) Stay abreast of technology
    4) Listen to your developers; don't assume you know more than they do
    5) Care about your projects and the people who report to you.
    6) Run interference for your development team. Keep them away from project hassles.
    7) Don't set unrealistic deadlines and expect your developers to work 80 hour weeks to meet them. Your developers should be involved in the timeline.
Randy Minder
A: 

Management is often about communication. You want to become the person that people ask for advice, who understands requirements, technologies, processes and risks. To get there, I share the views of Chad Fowler in his book "the passionate programmer" where he explains why "marketing" for programmers is important. You need to learn who are your shareholders and what they need to know to move on.

In general, I prefer a working style where communication about resources comes first on control of resources. If you share this view, you'll find talks by Jason Fried or the Pixar way on project management interesting.

poseid
A: 

How to Win Friends and Influence People has some points about handling people and being a leader that I'd consider useful.

Managing expectations would be a key part as well as understanding there may be many different roles that people may have in a project that you have to make sure they do their part. While developers may seem like the obvious part, there can also be testers, business analysts, stakeholders, architects, sysadmins and others that you may have to understand their view of the project that may be radically different than yours. Being empathetic is important here I think in addition to knowing the details and how at risk is the project.

My suggestion is to watch some project managers around you and see if you can find a few things they do well and a few things they don't do so well to help focus your skills while at the same time seeing if you can get mini-projects or assist on a project to see more of what that role covers where you work.

Good luck!

JB King
+10  A: 

The best project managers have a couple of simple traits, they are organized, they can communicate well with others, they are calm in a crisis, and they are realistic.

In the bad old days before personal computers, I was a project manager for manpower studies. I managed 30 teams of people working all over the world and never missed a deadline or went over budget and my teams had work that passed the stringent quality control standards every time. I did this with no fancy software, just a pad of paper and a telephone. What I did was this.

I documented every call/meeting so I could answer any question anytime about what decisions had been made or what questions needed resolution. This take no extra time if you write the notes during the conversation or meeting.

I never let any project go more than a couple of days without talking to the team lead about it. (Think about how often a PM has ignored the team for months and then suddenly is all upset to find out things are not going well and how annoying that is.) When there was a problem that was going to cause a delay, I knew about it the day it happened (not three weeks after the deadline) because I asked my team leads to tell me and because I didn't punish them for telling me about problems, they were willing to tell me about them. Then I adjusted the deadline with the customer to account for the delay. If the delay was something I could clear up, I did so.

If there was an unanswered question that caused the work stoppage, I looked for other tasks not affected by the delay that could be done and asked them to work on those until I got the answer, then I went out and made sure I got the answer ASAP. If the delay was in the critical path, I made sure everyone who needed to know about the delay knew about it as soon as possible and knew how it would affect the schedule and waht action needed to happen to fix the delay.

We didn't have the problem of scope creep, but it can be handled in a simlar way. Anytime the scope gets added to, the PM sends in a new cost estimate and a new deadline to the customer. Anytime a delay is the fault of the customer (failure to provide needed information or files for instance), the deadline is moved by one day for every day they delay and the customer is told in writing why the deadline is being moved. We do this here and it has cut down on scope creep a lot (funny how there being a cost to adding new features makes them less attractive) and has definitely expedited the delivery of things we needed from the customer.

I spent a lot of time talking to the managers of the teams working on my projects, making sure they knew what I needed and expected from the team and what types of people I needed on the team and why. I made sure to help them out when they were in a time jam when I could, so they were willing to help me out when I needed it. I said please and thank you. I made sure the teams felt appreciated and I told their bosses when they did good work.

When a team was, shall we say, sub-optimal, I went out to the site where they were working and made sure they were trained in exactly what was needed. I wouldn't do that as a PM, but if the technical lead needed training, I'd make sure he got it. And I'd make sure to know if he felt the team needed some training to be more effective and then push to get it to them. Or we would discuss how he would manage the less experienced people to make sure to grow them to the level of performance we needed.

If work came in that was not correct, I sent it back until it was correct with an explanation as to what was wrong. PMs often have to act as testers, so I would check things against the spec to make sure things weren't missed unless there was a formal QA team (even then I would spot check, my business knowldge might mean I would see things a tester would not). But more importantly, I made sure they clearly knew what they were to do (it's alot easier to work from a good spec than a bad one) because it's easier to avoid a problem than to fix it.

I allowed time in the schedule always for unanticipated problems because all large projects have them. I never assumed an 8-hour or more workday per person when figuring time schedules. If you estimate that people will work 6 hours per day on a project when they are assigned full time to it, you will be closer to right. People take vacation and bathrooms breaks and get stuck in HR meetings etc, you have to allow for indirect time in your planning.

Listen more than you talk. Be the person who clears the roadblocks, not the one who adds them. Make sure that both the team and customers are aware of changes affecting them as soon as possible. Know the business that you are writing software for and use that knowledge to questions specs and point out problems that you can see. When developers have a strong objection to something, listen and try to resolve with the customer and the devs. Know enough about development to know when it really is a problem and not just an "I don't wanna do that boring thing." You are the conduit between the customer and the team, be sure to keep the information flowing.

Being a project manager isn't for everyone. It takes a strong personality and self-cofidence as you will often get caught between the unrealistic expectations of both the customer and the developers. You have to be the one to pass on the bad news and that isn't easy. It helps to remember that the earlier they hear the bad news, the less upset they will be. It's alot easier to know about the added scope three weeks from the deadline (and knowing the PM will be pushing the deadline back to accomodate the change) than the day before and it's a lot better for the customer to know the deadline will be moving weeks ahead of time rather than after it has been passed. In some ways it's more satisfying because you can fix problems before they get out of hand and you have some real input into how things will be done. But it isn't coding and the people happiest coding may not like the people aspects that you have to manage as a PM.

Office politics are something a lot of developers who don't plan to move up in the organization (except to senior dev) tend to ignore or complain about. A PM doesn't have the luxury, office politics are how he will get the right people assigned to his projects and how he will be able to survive being the bearer of bad news. If you are interested in this role, you need to study office politics.

HLGEM
+1 what an exceptional answer!
Totophil
Thanks for a well thought-out answer. I am all-too-aware of the role politics plays and I'm not sure if I am cut-out to naturally handle this side of the job. Can I develop into somebody who excels at office politics? Time may tell...
adpd
A: 

Based on my experience, losing your desire to live. And, no, I'm not just being facetious...

Whilst project managing invariably pays more, there is no disguising it is dull work with little room for self-expression or creativity. You will long for some interesting programming rather than endless meetings, reports and Microsoft Project... Believe me, I made the transition thinking I was advancing my career and regretted it, and gladly went back to coding. Think very carefully if this is really what you want to do.

Dan Diplo
Dan, I appreciate your insight and experience. This is one of the concerns I have. We all want to "develop" ourselves and shape our careers. I feel I am coming to a crossroad where I have to decide which path to take and I am pleased you have highlighted the less glamorous side of things.
adpd
+2  A: 

One of the ways of moving into project management from the dev background is getting formally trained and applying for entry level PM jobs. In UK there is a number of universities offering full-time, part-time and distance learning degrees in Software Project Management:

The benefit of the formal training is in its systematic approach that will guide you quickly through the basics and provide understanding of what current state-of-the-art is. That is to say a degree in software project management will enable a broader outlook than getting a single methodology accreditation such as PRINCE2. As a bonus, everything else being equal the degree makes PM more attractive for potential employers.

Another way is to gradually assume more responsibility at your current workplace, however without good understanding of what project managers do, or should actually do on day to day basis, what current state-of-the-art is and what is worth striving for, it's rather easy to fall into the trap of mediocracy.

Yet another, third way is to simply choose a real problem, write a piece of software solving it and put it into the wild and acquire some real users. By starting with a problem and arriving at a solution, having to make all the decisions without the usual backing of corporate infrastructure a developer can actually learn a great deal about real-world project management.

As far as the traits concerned, brilliant project managers are result-oriented, emphatic, polite and treat everyone with dignity. They can grasp and clearly formulate problems, analyse them from different angles be it technical, legal, political, economic, social or any other dimension.

They are practical in a sense that they're always aware of the constraints that exist in the context within which the problem has to be solved, yet they have the courage and ambition to pick a great solution.

A great PM willingly takes ownership of and responsibility for the project yet gives the control over individual tasks to project team members.

Best PM's have the ability to create a structured way, a framework of arriving at a solution what is clear and universally accepted.

They understand that any monitoring and management information is also a burden and are careful not to place this load excessively onto engineers. Such PM's take care of the administration letting software developers to concentrate on getting things done. An experienced PM knows that 100% utilisation is a myth and there are times of intensive work intermingled with relatively quite periods. The same applies to a solution, since great solutions are never 100% utilitarian and great PM's are prepared to give a bit of leeway and expressive freedom in return for greater sense of ownership and identification with the project outcome. Good software PM's don't think of team members as "interchangeable resources" that can be brought in and disposed of on demand and, in fact, any PM saying "resource" whilst referring to a person is not worthy the title.

Successful PM's are friendly and approachable and willing to give their time and attention to team members and stakeholders when needed. They're fully aware that others see them as a company representative in a position of power and try to consider the impact of anything they say and equally try to abstain from taking sides, however the best ones still are not afraid to retain their personality.

Good PM's are akin to good software developers in that they are able to think more than one step ahead, it's just that they plan various routes the project and it's environment might take, whilst developers plan the ways their code is going to be used.

Excellent PM's capable of building great software teams don't cherish any delusions about own intellectual superiority, they see project management as just another job that needs to be done well for the team to progress and realise that they well might be working with people that are smarter and better informed. Treating people with dignity implies forming a structure where professional opinions are respected.

One of the most difficult aspects of being a software PM, one that requires self-confidence and courage as a personal trait is the frequent need to defend an estimate or deadline that is based on soft data, that is to stick to your guns under pressure from stakeholders and keeping people around from slipping into wishful thinking.

As far as the job satisfaction is concerned the PM role is often overly glamorised. In actual life, at least half of the time is spent doing routine administration tasks, co-ordination, chasing up, orchestration, monitoring and writing reports. Most software projects in the real world are just not large enough to afford any support staff and these tasks end up on PM's lap. This also means that most project managers will have to work not on one but a portfolio of 2-4 projects and it will be difficult to dedicate full attention to any given task. Constant task and context switching makes it impossible to catch up once PM has fallen behind; the job requires strong work ethic and superior ability to stay organised.

Anyone who tries to avoid dealing with everyday routine tasks might find it hard to become a good PM. However these tasks will be taking less and less time as PM becomes better at them. Another infrequently advertised aspect of the job is the requirement to deliver bad news or to deal with emotionally immature or unstable individuals. But these tasks are just part of the package.

Exceptional developers are alike in that they take great pleasure in building new things and having control over the way things are done. The best thing about being a software development PM is the ability to contribute on stages and levels beyond code, have bigger influence over the shape of the entire solution, have a say on who is in the team, make sure that the right ideas get attention and largely determine the success of the project. In a way this magnifies the power of building new things tenfold.

Totophil
A thorough analysis that has sparked new thought (no small feat when we are talking about me!). I had not really considered going down the MSc. route. I am now looking into some courses off the back of this answer. Am I ready to re-enter academia?!
adpd
A: 

You need to know how to work with People and have great People's Skill to get your work done and meet deadline.

Rachel