14

There are a few options you might consider although I wouldn't choose any of them as a preferred one. It depends much of your context and it's your choice to be made. Do what you are told to. I know many engineers who would simply reject to do the work in a way they think is wrong. Yet it is easy to forget that we work in a specific organization and we are ...


13

People Who Add Real Value Aren't Hated Good project managers are generally liked by the team as a whole, and by the organization in general. This is not only because they get things done, but because they act as facilitators for communications between parts of the organization such as stakeholders, management, and the development team. In addition, the ...


7

Your interactions with team members are the key part of being a PM. You will always have some sort of relationship with them, good or bad. In the common case where a PM has zero real power in a company, having a good relationship with those who do have power becomes overwhelmingly important because if you don't have someone who is willing to back you up you ...


6

I don't believe that PM's are normally hated; I can't cite any evidence to support that notion. PMI has lots of evidence that indicates that strong PM practices are associated with successful projects, and all other things being equal, people prefer to work on successful projects than on failures. I admired the good PM's I worked for even before I knew ...


6

Nothing in Project Management is Free It is usually very difficult to explain to management that it will take time to repay technical debt and that the team will be even slower refactoring rather than delivering features. You already know the answer: you can't create a bigger pie by carving it into more slices. Ultimately, a team has a finite amount of ...


6

My day to day job consists of sprint planning, user stories, coaching, being involved in software architecture, reports, sprint retrospectives, user acceptance testing, managing resources/ stakeholder expectations etc etc Wait a second. Why are you doing software architecture? You are managing the project. Your technical people should decide on the ...


5

The first counter to 'this requirement will be easy to deliver' should always be ask politely to list down the risks involved. Such unfounded claims are done by people who want to boast or want to challenge the team off a cliff. The art of war in such situation is to transfer/overload ownership by asking counter specific (not open-ended) questions to the ...


5

I am a developer and after reading the discussions going on here I would like to answer from my perspective. One thing I have really appreciated about non-technical project managers is the fact they think their dev team is amazing because they pull off the feats they do. They also ask a whole range of questions to understand. In contrast when I have had ...


5

It can be a copout, but in my experience, most of the time when someone says something like "relationship building is a cop-out", the person saying that really does need to put more effort into building relationships. Let's look at some hypothetical scenarios: Al's engineers need some mockups from Beth in graphics department. Al says to Beth, "I need these ...


5

Yes, ignore her. There is no reason to be hated after a project. Mutual trust and respect are what you are aiming for. That's the thing about the limitations of using experience to try to determine how good someone was. The worst of the worst will have experience.


5

I use International Labour Law of Prof Blanpain. http://www.ielaws.com/blanpain.htm and http://www.kluwerlawonline.com/toc.php?area=Looseleafs&mode=bypub&level=6&values=Looseleafs~~IEL+Labour+Law~International+Monographs~International+Labour+Law&raw=true He was also my Prof in International Labour Law.


4

I kind of understand how you feel now, but don't think about quitting just yet. If you don't have the necessary background to support yourself without a job, you'll have to look for a job before quitting and you'll have to work in the very same environment in the mean time. So it doesn't look like a win to me. If I were you I would find out why the team ...


3

I'll give the same answer I gave in the "Non-Technical PM" question. It applies equally here. In your specific case, you need to educate senior management so you have their support. And then you need to give the team more visibility into what you do day to day. Make it clear that they would have to share this work if you were to do coding work. 3 down ...


3

Adding to the arguments already mentioned by others, I think this depends on several factors and overall — organizational culture has a significant impact on how PMs are perceived. There are places where it's "more OK" to be against the Project Manager than elsewhere (it's that guy who's poking his nose into everything — from one point of view). By the same ...


3

There is a chance of deterioration of relationships with other developers if you are now 'managing' the work of the same developers whom you have had earlier 'lead' as a technical lead. It also depends on your current relationship with the team and how they perceive you now as a 'manager' and they will now compare you with your earlier role as a technical ...


3

While I agree with David and Mark that trust and respect should characterize the team's attitude toward you, must warn you that by becoming a PM you will gain more visibility; you will be judged more severely - such is human nature, as always, it's "Us vs. Them" and "we" get some slack while "they" are censured for the same mistakes. Fortunately, as a ...


2

"There is more than one way to skin a cat." I can say this without knowing what you are working on and either design: Both designs have its benefits, costs, penalties, and risk. Since you are not in charge, your job is to design an alternative, conduct an analysis of alternatives, find risks for all of them, make a recommendation, then do what you are ...


2

Use SS with the number of days lag you need. Then load the duration of the succeeding package so it will end the same as the preceding task. When you baseline, the finish dates will end like you want. That is the only time when you need the ending dates to match. After that, your finish dates need to move based on how you load actuals, which is how you ...


2

Here's a simplified, idealistic example of what is usually happening in this situation: Management has Team A that they think has a velocity of say 100 story points/iteration. Management thinks Team A can deliver 100 pts of business value stories each iteration. In reality Team A is is always pressured to provide more and really they can do 90 pts of ...


2

Relationship-Building is One Tool Among Many Relationship building isn't a cop-out. However, in your specific case, it is the wrong tool for the job. In many cases, a project manager has no real power; he or she must perform duties through influence rather than command-and-control techniques. In your case, you make the point that you can do neither. You ...


2

What you need to uncover is the driver behind the 'this will be easy' rhetoric. Is it innocent optimism? Is it designed to keep sponsors interested in funding this project? Or is it designed to insulate themselves against a risky project such that they can point to another group or individual--such as you--when and if the project goes south? No matter ...


2

Stakeholder analysis can get as sophisticated and detailed as you want to make it. There are practitioners that specialize in this and this effort can get quite exhaustive, time consuming, and expensive, but very valuable. Since you are new to the PM role and do not have experience with stakeholder analysis and management, you can design an effort that is ...


2

Mapping stakeholder interests is an always-ongoing activity. It should never be complete, merely reviewed. Organisations revolve staff through Projects and Programmes constantly so stakeholder maps should be updated as often as required. Asking Directly As a Project Manager, you will receive very little guidance about how to run your project and that level ...


2

One is tempted to do these to manipulate dates for just-in-time work: Install pump -SF-> Deliver pump; Construct platform -SF-> Platform pre-construction meeting; Commission Eqpt -SF-> Energize equipment. Although this gets the dates where you want them, the logic flow is reversed from reality. This messes up critical path and other logic analyses. Some ...


1

It sounds like you are half in and half out of the techincal side of things. I would advise removing yourself from all technical descisions, discussions, architecture, 'trying to make things easy' etc Concentrate on the timeline, budget and customer acceptance. Set challenges rather than specifiying solutions. re the bitchy dev. They need to be told to act ...


1

Overall, I think the answer to your problem lies in more transparency, but to get that, I think it may help to re-frame your issue a bit. It sounds like there are two things happening here and I think there's value in looking at them separately. The first is that the development organization needs time for things other than coding new features. This may be ...


1

Quick Answer: During each sprint planning meeting, discuss technical debt issues and create a placeholder card in each sprint with 5-8 or so story points that will be used to address re-factoring. You can do this as well for releases. This is a way to incorporate technical debt in your teams planning and the best way to describe it to management, is ...


1

I don't know that software package, but it does not make logical sense from a scheduling point of view. Consider the case where your development is ten days long and testing is also ten days long. But then you need to do more testing so make it 11 days- With both SS and FF constraints the package will not be able to move either the Start date or End date to ...


1

For me, it's somewhat of a cop out. It's like saying 90% of project mgmt is communication. No, 90% of pm is knowing 'how' and 'what' to communicate and why. Simply talking (communicating) about it isn't going to change anything, and it certainly not going to get the project done. So yes, you have to build relationships. But you have to know 'why' you're ...


1

TL; DR Consult your Human Resources department or your Legal Department about how resources can be allocated. This is an HR/Legal Issue While the answers to your questions may impact resource planning and project schedules, determining the answer to labor-related questions is ultimately not the job of a Project Manager under any methodology of which I'm ...


Only top voted, non community-wiki answers of a minimum length are eligible