I am excited and terrified (at once hehe) as I have an opportunity as a “jr. project manager” for a web/software developer to take on sr. project management responsibilities. The company is small and I do not have many experienced mentors in the field (there are only two other project managers in separate divisions of the company.
When I first came the place was in chaos. Projects were not hitting their budget mark, and they rarely had concrete deadlines/priorities.
I am trying now to create a process, a series of workflows, and I am defining what a particular project should do/it’s risks/etc in a Project Plan/Project Requirements Document.
Where I am having trouble is priority, scheduling, and the other critical areas of project management.
I know what’s on our plate to do, but it all seems as though we have to do them all now (and we can’t), and too much burden is on my senior developer to help all of the other developers.
I am thinking I might have to create some concrete days for a quick status meeting (every tuesday), and assign workflows directly to team members (now I am sending it to the lead developer, hoping he can advise them on how to do it).
I think these status meetings can be a structured way to shift priority, and I think by directly tasking everyone on the team with parts of the project, based on how we split it up during a kick-off, it takes some pressure off the lead developer.
Is this a good start? I just feel as though I am in over my head and I really like the job but need to get better…fast.
This is the heart of your job. Yes, everyone wants things done right now, and no, everything can’t be done right now. The job of the Project Manager is to be the liaison between the workerbees (the developers) and the company management who is screaming for stuff to be done. You need to prioritize, and saying “everything has to be done NOW” is not prioritizing.
Having meetings to assign work is fine, but it won’t fix the problem of too much stuff needing to be done in too little time.
You have to be the one to set expectations correctly. If Management is pushing too hard, you need to figure out how to reset their expectations to something that the development team can deliver. On the other side, you need to work with the developers to come up with schedules & processes that you can turn around and show Management so they feel confident that work is progressing.
Just the other night I attended a meeting at the Project Management Institute here in town, and the speaker had some good insight about the difference in roles between the BAs, programmers, and the project manager.
One thing to keep in mind, as a project manager your loyalty should lie with the company - not the client. It’s the job of your BA or project team to advocate for the client’s best interest, but as a PM you are there to ensure that the project is successful for your company.
This means that you get to decide what is highest priority, and how things should be handled, and manage accordingly. Don’t let your client or your project team set your deadlines or goals.
If you’re having trouble deciding for yourself what is important, you might want to sit down with your team and go through some analysis. Do a magic quadrant to figure out just where on the spectrum of “important” each of your tasks are. You’ll find that not all of them are equally important, or that maybe some that are less “important” really should be done first, because they will make it easier/faster/cheaper to get to other important issues down the line.
Above all, use your best judgment and be willing to back up your position. If you feel strongly that something just cannot be done within a given time frame, explain why and offer an alternative. Always have a solution. Your first job is to make sure the project finishes within scope/budget/timeframe, but if you see that is not possible your second job is to find a way to mitigate the risk.
Definitely have the status meeting, but keep it short, which means you are going to have to define what you want to hear and cut off ratholing.
Before you create processes - do you know where the project is? What objectives are people going for, whether documented or undocumented, and where are they on them?
Once you know this, decide what objectives should be delayed for the moment, which will involve understanding dependencies and where people are. It doesn’t make sense to trash an objective someone is within a week of hitting, since their morale will take a hit and there is a much bigger chance of error when it is restarted. Beware of objectives that are said to be a week away but are actually several months. (We’re 90% done with debugging, honest!)
The root cause or project problems is either a lack of understanding of the objectives or a lack of resources. Once you figure out where you are, you’ll need to assign resources to get the more important objectives done. I like delivering something, even if not complete, over working on everything and being very late. Your situation might not allow that.
Finally, the project management software I’ve used assumes you’ve already done all the steps above, and that you understand the objectives, schedules, dependencies, and resources. Then it can help you see how you stand. But if you are just guessing at the level of effort needed to reach a milestone, you’ll have pretty table full of garbage. It is no substitute for understanding what is going on and being realistic. I worked on a very large microprocessor design project where we had to input our progress and where we had a few people doing project management full time. This did nothing to make things better. It’s no accident that the examples used for this software are things like building a house or putting on a play. Some software projects may be like this, but your’s doesn’t sound like it.
So, take your class, but don’t expect any magic solutions. Plenty of people who managed disasters have taken classes also.
It sounds like you’re off to a really good start. Although I’m in product management and development, a LOT of what I do is delegation and project management. In my experience, I generally follow the following formula:
Meet with management to understand the project and the scope. Make sure everyone agrees and you have a clear idea of what’s expected of the project so you can put together a clear set of business requirements.
Pull together business requirements, ask questions, get questions answered by your management.
Kickoff meeting with other players with business requirements provided in advance, plus an assignment of duties based on your understanding of all the players’ roles & responsibilities. The meeting should clearly communicate to all parties what the vision is, what you want to get out of the project and result in either an agreement between all parties of what is expected of them (unlikely during the first meeting) and takeaways for you to answer. One of the biggest problems with projects I’ve worked on is an unclear scope of what’s expected of everyone. If you’re directing people to work on a project and don’t tell them fully what the end result should look like, it probably won’t wind up the way you and your management want it to.
Get questions answered by your management, if there’s a question over who needs to be doing what (i.e., another department thinks yours should be handling a task you think they should handle) take it to your manager and work out a sound business argument as to why the other person should take it. Alternatively, you may find it’s just easier for you to do it.
Have another meeting with all parties with revised delegation. Get them to agree; if they don’t, revise and resend. If they can’t come to an agreement, escalate to your management and theirs (diplomatically) so they can duke it out.
Send out a work plan, ask everyone to revise as appropriate. Once done, send to your management.
Once a work plan is established, status meetings are a must. Be sure to get people to update the plan weekly before the meeting so you can go over it as a group. Not only does this keep people on task, it also helps you know if a bottleneck exists and who’s causing it. Perhaps invite your manager as optional so they can drop in.
In addition to the above, I’d say a post-mortem is a good idea, especially for a large project. If you have a “lessons learned” meeting a month or two after, you’ll have greater insight into what worked and what didn’t and can get some feedback about the success of the project.
As for deadlines, you’ll need to know from the other players who are doing the work how long they think their part will take. That’ll help you pull together the work plan. Basically, tell them when your group expects to have the whole project done and live and tell the other players to work backward from there.
Also, if you’re having trouble getting someone to move on their items, know when to escalate to your management (as in, drop by their office/cube and give them a status, letting them know as diplomatically as possible what the holdup is).
Finally, be as organized as possible during the status meetings. I learned this the hard way, but if you don’t take 15-20 minutes to prepare in advance, including thinking of questions people may have, questions you have, what you want to say and how you want the meeting to go, you may find yourself with a really awkward silence and a lot of people waiting for you to direct them.
Any advise guys?