|
The situation is such that after having been at the company as a software developer for almost 7 years, due to certain unfortunate events that have happened to previous PMs, I have been promoted to continue as the project manager for a team of 10 people. I did enjoy writing specifications and deving the software, and to a lesser extent being the scrum master, but now it is time to get adjusted to the new role. My question is though, what do you think is the role of the PM (Project Manager), and how to be a good one? So far it seems I've been doing a lot what I've previously done (speccing new features), but with more deciding and time scheduling, and less coding. And more internal communication. Email, that takes a lot of time with customers. My list so far:
What have been your experiences with project managers or with someone you know who became one? tohveli fucked around with this message at 17:18 on Mar 8, 2015 |
#
?
Mar 8, 2015 17:06
|
|
|
|
| # ? May 5, 2024 18:13 |
|
|
Large organizations would have a product manager who determines the business side, a development manager who drives getting those done, then you may have project managers who tend to be the unfortunate one who has to chase people all day to meet there projected task dates and join each and every meeting for note taking.
|
|
#
?
Mar 8, 2015 17:32
|
|
|
PM is all about risk and schedule management, and clear communication to stakeholders (dev team included). No one likes surprises - so contain them early when you see them and show how to move forward to get the project shipped as expected. You cannot avoid surprises, they happen all the time regardless of how great planning is. No one really cares what it takes to deliver either, except you, even though they say they do; so figure out what each stakeholders preference for detail is and customize your communication to them. Now, the best PMs manage the team doing the deliverable work by understanding the job they do, being supportive of them in getting it done, and relate that info the desired outcome of the project. Sometimes that means rolling up the sleeves and reviewing the code, providing input to design, clarifying requirements or reducing scope, sometimes its more HR related to coaching / self confidence / experience etc; you have to make judgement calls as to where your time is best spent to manage the risk and schedule management. Always look 2 steps ahead to next milestone and the one beyond that so you can steer the ship smoothly. If you are in a bigger company (10 people in your team? probably smaller place) you will likely be less hands on and more communication and planning.
|
|
#
?
Mar 8, 2015 17:38
|
|
|
tohveli posted:* Provide the team and stake holders a roadmap of major features to come (e.g. gantt chart for the next year) quote:* Have the final say if team has multiple varying opinions In my experience it's best for the PO to stay well away from technical discussions. A PO's primary job is to deliver features. The teams job is to write them in the best way they see fit, and chances are they'll choose some time-expensive chromed out solution (as is their wont). A PO will have to negotiate with the team to come to a compromise. If the PO always has the final say on how they do it, then it's no longer a negotiation and the PO will tend to choose the shortest cheapest path to get what they want. This often ends up accumulating technical debt and the internal quality of the product goes down. Let the team decide how to implement, but be prepared to negotiate if their proposal is too expensive. quote:What have been your experiences with project managers or with someone you know who became one?
|
|
#
?
Mar 10, 2015 06:51
|
|
