Jr. Project Manager...has some rookie questions :)

In My Humble Opinion
1

Hey guys,

I graduated from college about 2 years ago and just left a business development job for a Jr. Project Management job for a web development company. I have web development experience (freelance)-but not much PM experience.
I have been reading as much as I can regard the role and for once in my life I think I have found the perfect blend of a planning role and something pertaining to the web, but I need help on getting better.
While officially I am a Jr. Project Manager, I am not being mentored by anyone, and I am managing the project on my own. I manage project for a team of three .Net developers, two front-end/graphics guys, and a business development manager (I also pull resources from the other side of our company).
The division I am in is new, and separate from the more established one, which focuses on a specific big client that we do most of the web work for. We were set up as a backup, in case that relationship goes source (we work on small 30,000-150,000 dollar website/software application projects).
I have been left to figure out how to do the role, and I have identified that it is necessary (we were missing deadlines, going way over budget, and the team rarely remembers what tasks need to be completed from a high level, so I have started by creating spreadsheets that connect to the system we use to report hours to overall task categories (i.e. graphics, development, etc)-and the spreadsheet compares actual hours on project-specific tasks vs. budgeted low, high, midpoint. This helps me figure out what we cannot spend more time on, and I am going to use it to create a “lessons learned document that highlights what went wrong.” I also created a weekly status report that basically shows some milestones (meetings, etc), tasks that were completed that week, and tasks that need to be completed next week/tentatively-with names associated with each task.
The status report is given to my guys, and I meet with them in the morning and a few other times individually to go over what needs to be completed today/weekly.
I then typically look at the work, ask how much more time they need, and try to figure out where we are in terms of budgeted-time.
I also am meeting during my lunch with the lead developer on my team, and we are writing out the process (from sales to kickoff to finished product), and we are going to start defining roles within this detailed outline, once we create a formal process within each step. I think this will help make results a little more predictable and get people a little more on the same page. For example, I think the lead developer should review his teams code, and enforce coding standards (he does not do that now). I basically want to get to a place with this where he manages the technical standards and I manage the delivery/business requirements (budget, scope, time, etc).

The problem I am having is formal resources. While I have my spreadsheets that pull budget data, status-reports with weekly tasks, and lessons learned documentation for the end of a project, I still think I need more formal tools to get me organized and on top of projects. I have been using Microsoft project to create tasks on a high level, but I wonder if I should continue to actively use it and adjust it during an entire project span? I think I am also missing something with an overall list of tasks that need to be completed (maybe Microsoft Project is the answer for that?).
Any PM advice for me would be great. I plan on becoming PMI certified and doing everything I can to be more effective. While I like documentation that serves a purpose, I also find my style is more involved (meeting with the team, having them sign off on things, and giving advice as it pertains to scope, etc).

Thanks for any guidance. If I could walk away with some useful advice, templates, or programs to use I would be in a good place. Also let me know of any books that might be worth reading on my lunch.

I thought when I signed up for the job they would teach me how to be a project manager. It turns out I have to teach them how to manage their projects :slight_smile: They threw me in and I am reading all I can to get better.

I have started to create weekly status reports with tasks for the team to complete (with their names next to each associated task), and I am trying to figure out how to effectively use Microsoft Project as a resource that will help me adjust as we begin to take on website projects, but I need some guidance.

I think I need to see what some key Project Management documents are, and I need any general helpful tips.

While I have a weekly status task list, I feel I need something that contains all of the tasks-since it all cannot be done in a week or two. I was thinking this is where Microsoft Project might come in?

Right now I am also sitting down with the lead developer during our lunches and writing out our entire process (from sales to kickoff to finished project)-and then we will define roles within this map.

I also think I might beg them to let me follow a project manager for the other division of our company, and they will pay for me to become PMI certified.

Let me know any tips, etc you might have. I am new to the role and love the concept. I think I can do the job well but I need some advice.

2

Well, speaking from the other side (I’m a programmer), I can tell you the some of the qualities of the best PMs I’ve worked with:

  • Don’t be an asshole. For some reason, there’s a big group of PMs out there who seem to thrive on pissing off the rest of their team. Sure, you’re the go-between that meshes together the workerbees and the management, but believe me, the projects will go better if you can manage not to piss off the engineers.

  • Do your job yourself. Don’t create elaborate spreadsheets then toss them to the workers to fill out every week. Don’t initiate meetings more than once, maybe twice a week, and restrict the meetings to 30 minutes or less. If you need statuses, it’s your job to run around and get them, or create a simple status form that can be filled out by the people on the project in a few minutes once a week or so. The worst way to get statuses is to pull people into meetings where everyone sits around for an hour, waiting to spend 5 minutes telling you their status. Rare is the situation that requires multiple long meetings with the whole team to figure out.

  • Did I mention that meetings are a waste of time? Well, not always, but 90% of them can be accomplished via person-to-person interaction, phone calls, or emails. Remember every hour spent in a meeting is an hour each person on your team is not working. If you’ve got 8 people in a meeting that lasts an hour, ask yourself “Is this meeting important enough to spend an entire day (8 people x 1 hour) on it?”

>>“For example, I think the lead developer should review his teams code, and enforce coding standards (he does not do that now)”

I’d let the lead developer run his team the way he wants. Your job is to focus on results - “What can we do to get Project X done within 3 weeks” or “We need to get the bug count below 50 bugs by Monday”. Whether or not code reviews and/or coding standards will help realize these goals are up to the lead developer.

  • Do have post-mortems. You mention this below, but I wanted to bring it up since I think they’re really important. Get everyone together and discuss what went wrong/right and come up with specific goals to get better on next time around.

  • Communicate with the other people on the project. If you’re using MS Project, print out a project plan (all gazillion pages of it) and post it on a wall that everyone walks by. Mark the project progress with a pen or yellow sticky every day or two. Send out emails with project statuses. Do not wait until the project is WAY in the weeds before telling everyone - trust me, nobody likes those kind of surprises.

  • Conversely, if things are going well, make sure everyone knows that too. It’s easy to forget to mention good things as well as bad. In my experience, positive reinforcement is the only way to motivate people; negative reinforcement mostly just makes you feel like you’re doing something - which you are. You’re encouraging your developers to update their resumes. :smiley:

Books:

Essential: Peopleware: Productive Projects and Teams. The bible on software management. If you read one book, read this one.

Also very good: Software Project Survival Guide A little more technical than the previous book, but still a good read for anyone on a software project.

3

We have a library of documents provided by our PMO (Project Management Office) - most of these are Excel Spreadsheets or Word documents.

Project just provides the task list and does the crunching that comes up with the Network Diagram, Gantt, etc. Most of the tracking and status, etc. is done in Excel and Word.

Best advice is to stay organized, and try to produce the RIGHT amount of project documentation. Documentation no one ever will need to read has been produced for no purpose - documentation you didn’t produce that could save your ass (a project manager’s job sometimes is to save their ass by saying "this is what you signed off on) could cost you your job.

4

This is good advice. The code monkeys are rarely going to be updating project stuff in any useful or timely way on their own (IME, anyway) unless you enforce it, and the best way to do that is to spend five or ten minutes a day with them individually going over the status of their projects.

Another tricky but invaluable thing you need to get your project members to do is to document every client interaction - the number of times a project or a client relationship goes sour because of miscommunication is ridiculous. That is easy enough to do if the primary method of communication is via email, but you’ll need to think about how you want to handle phone conversations and face-to-face meetings.

Most importantly, you need to be the kind of project manager that a team member isn’t afraid to give bad news to, and you have to be the the kind of project manager who is willing to inform the client that something has gone awry as soon as possible. In essence, you have to be the mother hen, looking after her chicks. If someone fucks up, that can be dealt with later, but you are the responsible one and you take the immediate flak. If you can do this well, people will want to work in your team, and that’s better and more productive for everyone.

5

Just an anecdote really but one of my all time favourite project management stories told to me by a programmer about a project manager we had on contract. On a previous project one programmer’s productivity had started to decline and no matter what Tony, the project manager, did it continued to slide. Tony was conciliatory but became really concerned whether he could keep the guy on.

Eventually the programmer revealed that he was building his dream home and was being fucked around by the builder and it was driving him crazy. Tony took the programmer to the building site and explained to the builder, “This is one of my best programmers but the way you are treating him is fucking up his work. And that is fucking up my project. If I have to come back here to discuss this with you again I will be very, very angry.” Now Tony is a really big, fearsome looking guy and this intervention put an end to the programmer’s problems.

Not the approach for everyone, but the important point is that there is more to your staff than what happens from 9 to 5. So pay attention.

6

I’m interested in this thread. I’m thinking of moving into project management, myself. I’ve been working closely with the PM on our project and it started out very rough, but is getting better with time. I find it interesting and the energy level seems to be right up my alley. I like a fast-paced environment and the satisfaction of creating a final product from virtually nothing.

As Athena said, pissing people off will just push your project into utter chaos. The tension created by this had our PM in tears and resulted in out-and-out screaming matches with internal people and the client! I befriended her at that point and acted as a go-between for her with some of the more difficult people on the account. Although I could see that she made some pretty big mistakes, our major problem was that the whole thing turned into a pile-on to the point where she was paralyzed by the fear of getting reamed out again.

Have you looked into your community college or continuing education offerings locally? There might be a workshop; something where other PMs in your position (as well as more experienced PMs) get together. You might be able to pick up some pointers and maybe even develop a mentor relationship with someone.

My place offers on-line courses and I’m hoping to get a feel for it through that and maybe some books on the subject. Good luck to you!

7

Is there a PMI chapter in your area? If so, that would be a good opportunity to network and maybe find a project management mentor, or at least real-life peers to bounce ideas off of. http://www.pmi.org/

8

I am a programmer who works on $30k-$150k projects. I don’t have much experience with bona-fide PMs tho.

One thing that stuck out is that you “meet with your guys in the morning.” You meet every morning? To talk about what’s up? That would drive me nuts. Like Athena said, meetings waste time. I’d much rather that the project manager know that it is going to take X days to do this bit and come visit me again on Day X so we can go over the bit I just completed.

Having a nice clear scope at the beginning is something I’d expect the higher-ups and the PMs to do. Then they pass it on to me and I do it. If I have programming questions I go to the lead programmer and if I have scope questions I go to the lead programmer or the PM. I don’t expect to have someone giving me daily directives or hovering over me to see how I’m doing. That is not the way to get things done realistically.

9

For some useful templates & such, check out www.gantthead.com.

10

Go read “It’s Your Ship” by Mike Abrashoff. While it’s not “all you need to know”, it’s a terrific set of object lessons in how to treat your people in order to get them to be committed to the same goals, work as a team and take responsibility.

I wish dearly that more of my past managers had read the book- the ones that I’ve loved working for and respected the most tended to align with what’s taught in the book.

11

I’m a project manager on large scale websites and advertising campaigns. My must-do list includes.

  • Find those seeds of destruction and eradicate them early!
  • Before quoting time - get buy in from your lead dev etc.
  • Jot a contact report to your stakeholders daily by four - this gives them enough time to respond to questions etc.
  • if scope creep occurs, reestimate immediately.
12

That is good advice. I am not a code monkey but a I am a developer but also the most senior of the senior project analysts that co-manages 40 people in India, and manages 6 extremely large client projects myself. I have the power to unleash 40+ people on a project if I need to.

With all that said, our former project manager ended up having 20+ Excel jobs all over the place including the web that our team was supposed to update. When our team failed at that, he started 8 am meetings once a week. When we failed some more, we had to attend 8 am meetings every day and some on weekends. He was a friend of mine before that and then things started to fall apart. I had two serious fights with him over that. He didn’t seem to understand that updating project plans is not actual work for someone that isn’t a project manager. I just wanted to get my version of work done and spending 2+ hours a day doing that was not helping matters at all.

In all others places that I have worked, project managers update the status reports based on feedback for those they represent. Do not make that mistake. Developers develop and project managers need to update the project plans just like the names imply.

Luckily, the entire management team quit recently and the new structure is much better.

13

I think I’m in love. Are you female and single, perchance? :smiley:

Seriously, though, this is dead-on. A project I was working on earlier this year was falling behind on handling bug reports from the alpha testing. The PM’s response? Daily hour to hour-and-a-half meetings to review the current bug report list with the developers & update statuses. :mad: Amazingly enough, the project continued to fall farther behind despite this active project management. Yeesh.

14

This will depend on your organizations culture and the type of project you are managing. If you are managing self motivated coders - then status meetings are a waste of time - have everyone fill out a SIMPLE status report as often as the project demands and remind them (OFTEN) that they shouldn’t wait for the status report to come to you with issues.

If you are saddled with an organization like mine, where every team member feels the need to be able to comment on the testing methodology of the person doing the testing (and probably tell him he is both taking too long and not being through enough even though they approved the testing plan), you’ll have LOTS of meetings you don’t feel you need to have, and a battle keeping people from revisiting EVERY previous decision (“we agreed to the testing plan…we agreed to the testing plan…”)

Other projects just take more collaboration. Some take working meetings - particularly if you have a very small slice of a resource, the only way to get the resource to work on your project might be working meetings, because then their time to spend on YOUR PROJECT gets put on their calendar.

15

I’ve been doing project management and project recovery for several years. I tend to use a file repository where team members and stakeholders can look at the files for any information they need when they need it, and an MS Project Plan (from high level resolving to individual tasks where needed) with a Risk and Issue log updated daily (usually created in Excel).

A few quick thoughts - how long are your meetings in the mornings? If you are speaking to your developers everyday it shouldn’t take more than 10-15 minutes total to run round the table and make sure everything is on track. (If you are using Agile you’ll need this daily - otherwise see if you can reduce this).

Rather than sticking to one method adapt it to fit the project - don’t create documentation or processes unless you are going to use it and don’t duplicate (full Prince2 is wasted on small projects: you spend more time on docs than on the actual work). There’s no need to create work for yourself, or your team. Don’t create processes for the sake of it - e.g. if you already have a timesheet system use that to track what the devs are doing, rather than make them fill in a seperate form.

Remember your crew are people - basic consideration goes a long way. If you need them to stay late, ask, say thank you and order pizza if necessary. Plan ahead to avoid this where possible. Speak to your stakeholders regularly and be honest - they will take bad news better with forewarning than if it is sprung on them. Your job is to make it possible for your team to deliver the project. If they are staying until 2a.m. because of a major issue, don’t ditch them and go home - especially if the client is also staying up…

When you are doing specs, ask your relevant team members for input - they should know their subject area better than you do. Also, if you are getting work in from external clients, try to make sure you have a change process built into the document they sign off on initially. It saves a lot of time later when they change their minds on what they want delivered.

Remember, project management is just applied common sense. Take what works for you in your situation and discard the rest. And of course, Don’t Panic :smiley: .

This sounds really familiar. If you were in the UK I’d wonder if we ran into the same guy.

16

Female, but married, sorry!

I’ve lived through the exact same scenario you describe. It’s amazing how many people think meetings = work.

Unfortunately Dangerosa’s scenario is familiar as well. I think that in some organizations, people like to have meetings because they are not very motivated to work, and sitting around a table talking about work is preferable to actually working. I can’t stand office cultures like that.

As far as working meetings… I actually don’t see an issue with that, as long as only the people who are actually working on the problem are involved. The meetings I really despise are the ones where there’s 10 people sitting around a table for an hour discussing something that only 2 of the people there have any real input on. The other 8 people sit there for an hour, trying not to fall asleep. Total waste of resources.

17

My favorite are the ones where only two people can do the job, but eight feel the need to attend so that they can make comments - often negative - about the job being done. Unfortunately, I’m in an environment where all the functional managers want a body there - even if the body they give me is useless in doing anything other than getting in the way of actual work being done and try and throw in random scope creep ('well, as long as we are…shouldn’t we also…" Not in my charter, sorry - move on). Then the functional managers don’t talk to their body anyway to find out what the project status is - its like they don’t trust me to give them status, but then, don’t talk to their people about the status.

I’ve have to talk in terms of resource cost to the project - that ten people in a room for an hour costs the company $1000 worth of time - and while I’d love to have their resource, I’m being pressured to keep project resource costs down.

18

Thank you so much for all of the advice :slight_smile: Athena, I am not telling the lead developer what to do in terms of standards-rather I am helping him define his role better so we have less broken code, and so my projects go smoother (he likes it).

Can anyone suggest what specific templates I should always use? I am doing weekly-status, lessons learned, and I am going to have the team do post-mortums :slight_smile:

What else should I have? Should I keep track of everything, in terms of task-time in MS Project? How should I keep track of all of the tasks that need to get done? Let me know of all of the basic forms you would suggest-and anymore advice would be helpful :slight_smile:

19

Depends who it is for and whose writing it - if you’re working with exernal stakeholders they may have a pro-forma you’d need to use. If you want your devs to do one for you (not recommended as it takes away from work time - if you are having daily meetings, you can get the information there) then keep it simple.

There isn’t really a standard weekly report template (most companies I’ve seen have their own), but usually its along the lines of:

  • activities planned,
  • activities accomplished.
  • activities planned for next week,
  • risks and issues updates and a
  • red/amber/green project overview of whether you are still on track, and if not reasons and ways to mitigate. This link has some details on them. Google “template project weekly report” for more.

With lessons learned, if you are running long projects you may want to ask people to write a few paragraphs when they finish their part - otherwise they may end up in a lesson learned meeting several months later trying to remember the details of the project, when they’ve worked on several since. There’s a basic temple for lessons learned here. Also, there’s not much point in doing one unless you act on the information you have gathered - otherwise you will just keep having the same issues come up.

If you don’t have a seperate time tracking system, MS Project is a useful way of keeping track of time spent against each task. Usually I produce the initial plan at a high level and then break it down into tasks by speaking to the developers. You can either give them access to add their time against the tasks, or ask them what they’ve done and fill it in yourself.

20

At one company we worked at, we had Bugzilla (a bug database) and all tasks, bugs, and suggestions anyone had all went into it. It’s not got a nice graphing feature, but as a coder, a graph is less useful than a itemised list that’s been sorted by priority and has your name stamped on it (not to mention that it’s a self-logging system as the assigner and assignee go back and forth in the comments section until the task is finished.) A hand graph can of course then be made for the higher ups but, like said, those are 90% useless from the standpoint of the coders.