Why project managers get no respect
There is not a child who dreams of being a project manager. Maybe a firefighter, a rock star or an astronaut, but a manager of projects? There’s something inherently dull about the words “project” and “manager.” They’re not terms that come to mind when people dream about future careers. And it follows that in the professional world saying you are a project manager won’t get you much respect either. To many being a PM means you fit this unfortunate stereotype: you were not good enough in your field to be an engineer or ambitious enough to start a company, and through politics and self-inflation, you find ways to take credit for the hard work done by others. It stings, but that’s the sometimes well earned stereotype.
Many PMs unintentionally reinforce this view by trying to get everyone to pay attention to the work they do produce: the meta work of spreadsheets, specifications, presentations and status reports, failing to realize that to most in any organization, these are the least interesting and most bureaucratic things produced in the building. This mismatch of value sends the PM and his/her team into a downward spiral: the PM asking for more and more respect in ways guaranteed to push people further away.
The core problem is perspective. Our culture does not think of movie directors, executive chefs, astronauts, brain surgeons, or rock stars as project managers, despite the fact that much of what these respected professions do is manage projects. Everything is a project. The difference is these individuals would never describe themselves primarily as project managers. They’d describe themselves as directors, architects or rock stars first, and as a projects manager or team leaders second. They are committed first to the output, not the process. And the perspective many PMs have is the opposite: they are committed first to the process, and their status in the process, not the results.
The result is that most of the world thinks of project management as BORING. Not sure how it happened, but instead of thinking of the great moments in PM history, say the NASA space race, The construction of the pyramids, the Empire State building, the production of every great movie, or any of a thousand great things made possible only by someone’s effective management of the project, people think of overdesigned presentations, epic status reports, and people who spend too much time creating meetings. If you are not going out of your way to separate yourself from the stereotype, odds are good that when you say “I’m a project manager” the person you are talking to puts you into a Dilbert cartoon in their mind, and you are the punchline.
People with job titles like “Program Manager”, “Product Manager”, “Information Architect” or “Quality Assurance manager” have similar problems. These titles all makes it hard to relate to what it really is that the person gets paid to make happen: a sure sign of title inflation, confusion via over-specialization, or abstraction from the real work. I suspect all of these folks have similar problems with getting respect from people when they introduce themselves with their literal job title (process), instead of what it is they help make (better results).
The news isn’t all bad. This lack of respect creates a huge opportunity for people with open minds. First, their expectations of you are low. Second, most projects are a mess in one or more ways. If you can provide clarity and sanity it will be noticed and you will earn more trust and authority. If put your focus on your teammates, asking how you can help reduce their frustrations and making that happen, they’ll return the favor. You’ll get more respect than you expect. And you may find that people start referring to you as a different kind of PM – one who has changed their opinion of what a good PM can do.
See Making Things Happen, my bestselling book on how to be a great project manager.
@JD
It shouldn’t be about knowing his business, you are there to deliver something for the person based on what they tell you. If with mock ups , and sending them SOW they are not specific enough that’s not your problem. You can’t let clients take advantage of you by doing more work than what was originally agreed for free which ironically impacts the company you are working for cash flow negatively since they can make more money charging for it.
In my experience anyway a lot of the extra work are small tweeks anyway which do not take a lot of time to do.
wrt to:
In my experience anyway a lot of the extra work are small tweeks anyway which do not take a lot of time to do.
I would agree that is probably true 75% of the time, but it can also be death by a thousand cuts.
One thing you seem to be missing is, if you did not document it in your SOW, it doesnt mean the client agreed to whatever you assume is not in there. To have a very bad example, if you buy a home off the plans and read the spec sheet to make sure all the trim and colors are correct, and the builder leaves all of his garbage in your house before you get it. Are you going to complain? And do you think he will say, it doesnt say that in the spec?
thats my last comment!
@JD
As I said you should get your client to review and approve your SOW before beginning implementation. Then if there is anything missing and they complain, it’s not your problem!
But is ‘get your client to review and approve you SOW’ not literally: “…trying to get everyone to pay attention to the work they do produce: the meta work of spreadsheets, specifications, presentations and status reports, failing to realize that to most in any organization, these are the least interesting and most bureaucratic things produced in the building”??
The issue is trying to get people to pay attention the these outputs, that yes, are disinteresting, but should be very important to them. Many organizations don’t have PMs that have the power to fire. If there’s anyone on the ‘project’ team in a movie production that doesn’t get with the program in this sense, the Producer can get rid of them. Rather PMs have to negotiate and report to get to the goal in spite of those that feel like SOWs are ‘boring’ and refuse to read them. Lol. Also, referring to your example above, directors aren’t the PM’s in the movie production. The Producers are. This is another example of what PM is being so much more disinteresting than the actual product itself. So much so that people often attribute the Project Management of Movies to Directors when in fact, that job is more aligned with the Producer. Nobody ever knows what the producer does, because they are so enamored with the director or has more direct control on creative decision making, but who is still… NOT the project manager. lol
There is a reason why project managers do no longer exist in agile methodologies : because in such methodologies, you can’t hide bullshit and what is useless to the project, and team. The emperor is naked there.
There are no agile project managers. That does not exist. Once you go Agile, the project manager no longer does exist. Because the developers together replace it.
You get a scrum manager, which job is to SERVE the developers. It’s a total reversal of what a project manager could have been in the old “grand-dad” waterfall method where 80 % of projects failed or failed to reach objectives.
100 % of project managers I have met :
– make me lose my time by explaining them stuff they don’t need
– keep asking “how much time wil that take ?” and can’t understand it’s a temporary value than can go down or go up dramatically (you can’t predict the future, no one can, so why ask me to ?)
– so clueless they come see me and ask “what can i do ?” well, do nothing. so I can do my job uninterrupted, how about that ?
We’ve gone agile, fired all project managers, we have 0 now.
We have scrum managers, fire and forget drones I use when I need something from another team, whatever, that is “blocking” the development process and they handle it while I do my job. They either do nothing and wait, or I ask them to do something : hey ! I need data X but it’s not in the database ! can you please go check the DB people so they either add data to a table or give me a new table with data ?”
@G
To be honest, I think that you are extremely harsh towards Scrum Masters, yes they are there to support you and get pieces of work from other teams, although I am surprised that is all they do? I am pretty sure their work extends to making sure Agile is being done properly and measuring performance using burndown charts…. but anyway that alone is an important job and without it you can’t do your job and sign off the project!
I once worked with a tech lead when I was a developer, that was extremely good technically but was a terrible manager. He had the following problems:
– Did not know how to motivate his team, and get the best out of them.
– Did not know how to delegate work properly, I guess sure if he learned agile he could do this better. He didn’t work in an agile way.
– Was terrible at resolving impediments. If there were project delays, grievances, his approach was to blame the developers.
Project management is not technical at ALL, but the hardest part of it is keeping communication lines open between different teams, and getting them work together to deliver a project. Only because you are extremely good technically, does not mean that you can do that well, in effect improving the processes of the operational side of the organisation.
I think PMs even in waterfall environments should be serving the team. The problem was probably not so much that you were wasting time with the PM as a developer, but that you were on a project that did not have a technical analyst. Organization always seem to think they can afford to cut corners in 2 areas: Training & Development and Business/Technical Analysts. The reality is Agile isn’t for everybody. And there’s probably 50 million different flavors of many places, when you look at it have a more adaptive hybrid with characteristics of both Waterfall and Agile. I’m typing this a developer of 15 years in the same industry I now am a Technical PM for and I remember my pain points with PMs as a developer, and I know the pain points I’ve felt as a Technical BA and a PM WITHOUT a technical BA trying to support a team of devs while leading an overall project and aspects that affect multiple service centers within a business. Uggghh. It’s rough from both sides of the fence when you just need the proper resources to sit in the buffer. Because honestly as a Technical PM, I don’t wanna be talking to you about the technicalities of whether or not something can be done (if I don’t already know it, given my past roles). I want you WORKING on them to make the deadline. Lol. Give me a Tech analyst please that already knows to draft these requirements, so I can focus on PM duties. Lol. But that seldom every happens.
You sound absolutely horrendous to work with and arguably the very reason as to why PMs are scrum masters are valuable.. You do realize that agile has estimation as a core element right? Jesus… Take a vacation
As a technical architect at a large MSP I completetly share this thought I would adjust this to 90%. I have met one phenominal project manager, his name is Paul and he works in the Bournemouth region, granted a couple of these points came up but not all.
“100 % of project managers I have met :
– make me lose my time by explaining them stuff they don’t need
– keep asking “how much time wil that take ?” and can’t understand it’s a temporary value than can go down or go up dramatically (you can’t predict the future, no one can, so why ask me to ?)
– so clueless they come see me and ask “what can i do ?” well, do nothing. so I can do my job uninterrupted, how about that ?”
Project management is entirely technical in the construction low voltage systems wiring world which is the physical layer for all to do their job in this discussion. The sooner this community realizes this the more open they will be to technical project management. The product development community would serve themselves well to train skilled technical developer personnel that are not PMs to be PMs within the their specific product speciality, specifically on the soft skills of PM. 100% of developers are to technical and have 0 business acumen and management skills. They are continuously blowing up there own project budgets and can’t even see it.
@Bob You have technical project managers, they are called ‘tech leads’, and are the go to person for all technical questions. Very often they manage their development team, but beyond that have very little influence over other resources in the project lifecycle, BAs, designers etc leading to bottlenecks.
A project manager is a facilitator. The PM cares about improving the delivery ‘process’ for all teams/resources in the project lifecycle, so that bottlenecks are minimised and work is delivered smoothly.
Once again, does not require technical skills, but understanding and knowing how to integrate project management frameworks (Agile, Prince 2, Waterfall etc) in a delivery cycle properly and knowing for what type of projects to use each framework!
A good PM is somebody who has strong interpersonal skills, many technical people are good technically, but find it hard to identify why a process is failing. More often than not they assume it is because of something technical. From experience, the reason why a project management process fails is not because a developer is incompetent, but because there are bottlenecks in the lifecycle – a resource is taking longer than expected; team members having grievances (personal or professional) or misunderstandings about how the work needs to be delivered leading to the developer to implement the requirement not exactly how the client wants it and so on.
Hence, I have worked under tech leads as a developers who fit this category, and were terrible to work under.
@bob
From my own experience I have learned that software development and software project management have become different fields.
The software project managers care very little about software development while the software developers care very little about project management. The interaction between PMs and developers/technical experts is relatively limited.
From what I’ve seen PMs:
– make request to functional managers for people to be assigned to projects; who really gets assigned is not decided by the PM but by the functional manager;
– create and update the project plan; all the information from the plan is not made up by the PM but instead it is being provided by the project stakeholders including by the developers (or their technical leads);
– ensure the team is working on the things that are in the project scope so all that is being worked on will eventually get paid;
– facilitate communication between all the project stakeholders;
– make estimates about the project budget;
– report the status of the project to all stakeholders;
– resolve non-technical issue that may arise during the project execution
– do other things related to the project but not directly related to the actual development process.
All the PMs who I have worked with were not involved at all the in technical aspects of the work preformed and were completely excluded from the decision process taken by the team. On technical issues they had absolutely no authority over the project team. The project team members were not even reporting to the PM.
Many experienced developers would simply refuse to become PMs because they would completely loose contact with the type of work that they like. For many developers the PM work may seem very boring and something that they would not want to do. Many developers may also lack the soft skills needed for such a job.
Developers who want to become managers will seek the line/functional management track which is different than project management.
Usually poor developers would be more willing to be trained as project managers since they would not be able to progress too much in a technical position.
Experienced developers would be tempted to move to project management if this role is combined with that of the technical leader. In some companies this seems to be the case so all PMs are actually experienced developers. I have never worked in such a company.
@Adrian83
I think that the problem with a lot of developers on here, is this whole idea that the only resources needed to deliver an IT project are technical folk, and somehow they are superior to non technical people in the digital world. It’s that level of narrow mindedness which is why a lot are not any good at it. They do not have the interpersonal skills to do it.
Non technical PMs may not be as technical but they will probably know much more about the business domain as part of their role than the average developer, which translates into creating roadmaps that stakeholders can understand, documenting risks, and working with cross functional teams that comprise of not only developers but designers, QA, business analysts etc. In other words, getting everybody to work together, not just one subset (the engineering team) to help the business meet their objectives.
Technical PMs on the other hand just care about technology, and how to get it to work. It’s important for everyone reading the comments section to be aware of the distinction between the two. In a well run business non technical and technical people work together. It’s not one or the other.
No, no, no. I didn’t say that developers consider themselves superior to non-technical IT people. I only said that many experienced developers would not trade their job for a project manager position that involves no or very little technical involvement.
The fact that you don’t like to do a job and consider it boring does not automatically mean that you consider that job to be inferior as well ( compared to yours at least).
Many senior developers have a passion for their work. If they were to become PMs they may not be doing the work for which they have a passion. Well they could still write code at home but it is not the same thing.
I am sure that many developers respect the work that the non-technical IT professionals are doing but they would not like to do it themselves.
Now regarding the title of technical project manager I am not sure if this is appropriate for a technical lead. Technical leads usually have very little to do with project management, they don’t manage the project or a part of it they just manage (from a technical point of view) a group of people, usually from their line of work, that are involved in an activity such as in a project.
Technical leads can also manage people that are performing work outside a project. For instance a technical lead could be in charge of a group of developers responsible for maintaining a software product. Since this technical lead would not work on a project he couldn’t be called technical project manager. I had this role during my career. :)
Looks like we are finally on the same page, after 30 posts going back and forth.
Let’s put this argument to bed. To summarise:
– Tech leads manage only a subset of the project, other developers
– They do not care about the workflow between other departments to ensure a complex product is delivered on time, or helping businesses define their overall digital strategy. All they are concerned about is the technical team, and what is needed technically to help a business meet their commercial objectives. The project manager does the former.
So they need each other. Discussion ended.
You guys could never build a construction project.
@SS
Yes they need each other, that’s for sure. However in some development projects, usually less complex ones, the company hires no project managers or non-technical staff but only developers or other technical experts.
In the above cases the developers have do to everything including managing the operational aspects of a project. Some of them many not be happy with this arrangement but they have no choice.
On the former project I worked on there was no project manager but only technical experts. The customer on-site technical consultant was dealing with project management issues as well besides his technical duties. He was some sort of jack of all trades: business analyst, solution architect, project manager, developer, he was doing all these things. :)
From my experience I have learned that there is very little similarity between the work of a “pure” (non-technical) project manager and a “pure” (technical only) technical lead.
The pure PM and the pure TL care about completely different things and depending on the organizational structure sometimes they don’t even interact at all during the project.
For instance a few years ago I worked as a technical consultant for a very large company and I delivered (from a purely technical point a view) a project to a department. I saw the PM only once and only to say hi and nothing more, all the communication was done through the functional manager who was responsible for the purely technical aspects of the project. The functional manager was higher in the company hierarchy than the PM who was just an ordinary employee with no direct reports.
@Adrian83
Yes, if the project is simple then there is no need for a non technical PM. By simple, I am assuming that the project has been fully scoped and you know exactly what needs to be delivered right down to how the User interface looks.
The commercial projects I’ve managed are not that simple, and during the project scoping phase a lot of discovery meetings are set up with the client, where the requirements need to first be established. If done properly, the developer does not need to get involved until the user interface and experience has been established by working with a designer or BA, at which point their role in the scoping phase is to just give technical estimates.
…can you see where I am going with this? Where the PM role adds value, is ensuring that the communication between the client, BA/designer and technical team is fluid. A good one is involved in every stage of the process and acts like a filter blocking the shit hitting the technical and non technical teams from the client, upper management so that they can concentrate doing what they do best. In your case writing code. This can become quite hectic when you have more than one project on the go running in parrallel.
I have also found where a PM adds value is defiantly if you are managing a long term business critical product which I am doing right now. A lot of the skills I am using right now is not technical at all, but based around helping my stakeholder understand and define the long term digital strategy of the product. That means I have to understand the product from a non-technical point of view, helping him identify what features to add into the product which gives the biggest business value…Yes, that means I have to produce a quarterly product roadmap, log all risks (operational and product based) in a RAID report, make sure the budget is being spent correctly, track deliverables and be dragged into tonnes of meetings with my stakeholder.
Can a developer do this, yes they can, but most are not interested and want to just write code and are not necessarily business minded.
It comes back to my earlier point Adrien, you seem to think like many other developers complaining about PMs that all that is needed to deliver a project is technical skills totally ignoring all of the other skills/people that are needed to successfully deliver one. That is the downfall of many technical people and why they do not make good managers since they don’t understand the bigger picture beyond the tech.
P.S.
Being a jack of all trades is not the answer either.
I bet your friend who was one was a jack of all trades, master of none and the quality of work would get killed by someone who is just a UI/UX designer, Business analyst, PM etc in the same way a full stack developer will get killed by a pure front end or back end developer.
Thanks for the nice words about project manager. And you are article is really inspiring.
Yes. it is sure not the documentation work. He need to put his complete mind in resolving lot of different types of issues as his day to day activities.
And It is not at all easy to work as a project manager. But working on challenges are always interesting.
Making twice as much as any ‘engineer’ (I came up through the ranks as one) makes the PM spot so sweet as green or stuck engineers flail about trying to find self-importance in the world. My check shows me respect.
I just stumbled onto this article, and managed to get through some of the comments from SS, JK, and Adrian83. I will offer my 2 cents as well.
I am an IT Project Manager, but I started off on the technical side, Cisco Networking. The article is about “Why Project Managers get no respect”. One of the key points made by the author is that the “Job Title”, Project Manager, is abstract and does not convey much about what one does. According to the author, it sounds like title inflation. He also points out that some Project Managers, per their actions, tend to confirm the stereotype. I agree with the article. The author is not saying that Project Management is a useless, rather that the title is abstract and does not say much to relate to the “real work”. In fact the author highlights numerous achievements in history, that were project managed. The only difference is that the Project Managers had other titles. From the discussion, I agree with most of the things SS said. I do not agree that he said the article was unfair. JK and Adrian83 are quite obviously developers, so I am not surprise. As SS pointed out, those guys do not even understand the role, so it will be useless explaining it to them. The Project Manager is not there to write code, make all the technical decisions, or know everything. Developers, and lot of technical folks do not have what it takes to be a Project Manager even if their life depended on it. They often lack the ability to see strategically, hence the sentiment. In my years of experience, it is the developer/technical guys that will vehemently disagree with someone that says that they lack vision, strategic thinking, and leadership skills. I have yet to find a developer/techie with those skills. The ironic thing is that it is the developers, more than anyone else on an IT Project, that need the Project Manager, but it is the developers that least think they need the Project Manager. Judging from they response here, another weakness of developers is clearly visible here. They do not do well with reading – heck they do not like it. Every role on the IT Project is essential. Good developers are tacticians who see details, but often that is all they can see. Great Project Managers must be able to see strategically, and operationally. Great Business Analysts must see it all – Strategically, Operationally, and Tactically. In fact, the key roll on an IT Project, in my view, is a GREAT Business Analyst. None of the roles are useless. They all have their value. A good saying that I came across is that “You cannot make a great product with 2 developers in the room.” That is VERY True!
Joined a very large company as a new project manager, was chucked into a hardcore dev ops project:
– There was no documentation
– Developers were essentially running the project
– They were not listening to my suggestions, and carried the mindset all that you need to deliver projects is technical skills and that is it. They felt like Adrian83 was going bang on about that PMs are an unnecessary overhead.
Outcome of project above:
– No strategic project plan = endless scope creep, technical and non technical from change requests or understanding properly how to start and finish the project.
– No strategic project plan = delays from not factoring in annual leave etc delays
– When resources were reallocated onto the project, often they were confused about what exactly to do.
– Team became disjointed, all the devs were working individually not as a team. Issues caused by dependencies arose. Some devs were coasting it.
– Devs did not have time to dev and attend meetings to inform key stakeholders of project status, causing further delays.
– Delays communicating with designers, other non related technical teams in the project lifecycle
…in short an ABSOLUTE disaster.
I have since introduced
– comprehensive documentation
– comprehensive planning
– I do a lot of stakeholder management, not make technical decisions, tech lead does that and I negotiate on his behalf with stakeholders often successfully.
This is why project managers are hired, they are there to keep things organised and help the team think strategically when delivering a project, not code. One management skill that is extremely hard to do is team building, getting people from cross functional disciplines to work together efficiently.
To conclude, Project managers are the gel that keeps people together, so that in this case devs can focus on what they do best, CODE.
You (the engineer) do the hard work and put talent in the work. A pat on your shoulder and the PM gets promoted with a raise. It’s not you that are brilliant in what you do. It’s the PM that’s capable of “empowering” people.
The problem in this case has nothing to do with the people or the jobs they have – if whoever is giving out raises doesn’t understand the contributions everyone makes (or doesn’t) then they are the problem.
Engineering is hard. Managing a room full of engineers to collaborate and make something good is hard.
The problem is that project managers don’t actually manage engineers. They like to think it this way but 99% of the time in their relation with the engineers they just ask questions, usually about the status of the work being done.
Managing means taking decisions that others must follow. I have never seen a PM to take decisions that the team members must follow.
Managing at low level requires taking decisions that are technical in nature. Because of this, engineers are not being managed by project managers but by engineering managers who are themselves engineers and by senior engineers who work as technical leads in different activities.
If you fire the project manager the engineers can still make something good by themselves, fire the engineers and you can’t do anything just with the PMs.
I am not saying that PMs are useless, on the contrary they are valuable to the business in most cases, but it is not their job to manage engineers or their work, they just manage the project at the operational level.
Adrian, only because engineers can build a product does not mean that they can run a project. I have worked in big and small organizations as a PM, the problems are the following:
– poor project planning
– poor communication
– confusion
Leading to:
– delays
– project going over budget
– angry stakeholders
This is where a project manager is useful, they effectively act as a buffer between the engineering team and other parts of an organization, and are often co-ordinating activities between multiple departments by filtering out the shit, unlike a tech lead who just cares about the technical implementation. A good tech lead will be working closely with the project manager to devise realistic project plans.
Managing a new project mid way through in a large corporate environment. For devs on here calling PMs useless, prior to arriving on the project the following was happening:
– tech lead not bothering to do ANY project planning leading to confused stakeholders over the status of the project
– tech lead borrowing resources from other projects without notifying other project managers putting his and their project at risk
– tech lead not defining the scope, not creating jira tickets, and not updating jira tickets
Hold and below the project is late.
Adrien you are right, to be PM does not require as much technical skill, but clearly they needed since I am finding their job is effectively to help people work together as a team and communicate. Otherwise the project ends up going into disarray.
I am a project manager, and what project managers do best for those who are purely non technical is notify the stakeholders that the project will be late because of x,y,z. the stake holders then decide between late or reduced scope. Could the engineer have told the stakeholders, sure, and I have seen them do it. At the end of the day, if the PM runs a project in which they do not control the resources, they are project coordinators, not managers, as they make no MAJOR decisions. Sure they can teambuild, ask how people feel, arrange meetings, but that is not making decisions. As such they should be paid accordingly, including myself. Now those people that can convince the customer that what we are delivering is in their best interest because we cannot deliver the contracted scope in the contracted time, those people should be in sales, but it is often the technical leads who do this very important piece. To all the PMs, look back on your projects, how many items were left open simply because the project had ended or the money was out. That is not a successful project, that is a PM patting themselves on the back for not delivering all of the contracted scope in the contracted time. Does your software have bugs that you didnt fix? documentation errors? customer has their internal people filling in the blanks you didnt do? Don’t call that a success, call that the degeneration of commitment to deliver on 100% of what you sold them. But I love the PMS who criticize the engineers for “poor planning”, when all they have done is kept their stakeholders up to date on their own inability to deliver 100%, and then called it a success. It’s like fake news.
Negotiating scope/managing expectations is a skill in itself. What do you do if the stakeholder is stubborn with timeframes? Right, there you go.
Where I am working I am involved in major decisions:
– I can decide which devs I want on the project by talking to senior management
– I plan the project, that means selecting the right methodology for the project, Scrum, Kanban, Waterfall etc and do the necessary documentation/set up etc
– If i am under resourced again I am involved in resource planning
The above has a direct impact of how much of the scope can be completed. A really good PM will plan it in such a way where there is enough buffer in timeframes to deliver what is needed. They will also have processes in place to adapt with change. If there are issues, which always happens, again a good PM will have good mitigation plans in place. If you have nobody doing this, it’s simply chaos as I have just found upon joining. Nobody will know what is going on.
To add working with stakeholders to prioritise requirements is crucial for good delivery and a skill. Lets assume you can’t deliver a 100% of scope, the key is to help them identify what is extremely important and get the resources to focus on that. A lot of stakeholders will want everything and are bad at it.
stakeholders want everything because that is what they contracted us to deliver. stakeholders shoudnt have to balance scope vs time. imagine if your house contractor said it was going to take a month longer, and will be over budget and then started to ask if you can switch out hardwood for lino.
You would say to him, it is fixed price, fixed scope and you advertised 1 year, please live up to your commitments.
ITs like we have set expectations that we will never deliver on time on budget AND the original scope
Negoitiating with stakeholders I find is a simple exercise. Get all the estimates from the engineers, put out the available options based on the dependencies(provided by the engineers) and then ask the stakeholders what they really need.
IT is more math in my opinion than negoitiation. And I say this because if the stakeholders want to do something within the budget that you cannot do, you dont take money out of your own pocket to hire more people to make it happen.
And that is the difference between the commitment of the house contractor and the PM. The contractor is obligated to deliver, PMs are obligated to bring things up to the stakeholders to make decisions. And that is why if you ask the house contractor how he did on your house he will say, I lost money, but my customer is happy, and I value that because he is my reference for the next customer. The PM and all the stakeholders do a nice dance at the end of the project and congratulate themselves on being on budget, and how everyone is happy (dont talk about schedule or reduced scope). So when you say you need a PM to plan and the engineers dont plan, why exactly do PMS think they are good at planning when PMS cant deliver the contracted scope in the contracted time for the contracted budget? I’ll answer that for you, because they put the plan on paper. Just because it is in paper doesnt make it good planning.And the minute you adjust the plan, I would ask isnt that bad planning, you just changed your plan? how is this different from the engineers who change the plan as they go? I’ll answer that as well, nothing except PMs put it into the plan and take it to the stakeholders, or if they have budget, go get more resources, if they are available. My point is, it is a simple process.
1. Ask for status updates from engineers
2. If not on track, see if more resources available(if you have budget). If you dont have budget, go see stakeholders and tell them it will be late or ask to reduce scope
3. document stakeholder decision and do what they allow
repeat steps 1 through 3 every week
Jan, if project management was that simple, why do companies continuously hire project managers and pay good money for it??? Clearly A LOT of companies see the value of hiring PMs to help keep their projects on track, which is why I find this whole discussion ridiculous.
Management is an extremely stressful job, especially when projects fall behind schedule and the situation needs to be mitigated or when outside factors are trying to derail your project – last minute change requests, resources being pulled etc. For example, I have a constant battle with senior management to protect my resources at all costs to get work delivered.
As for stakeholder management, there is much more to it then getting estimates from devs, one of the challenges I have found time and time again is where their estimations are wrong!!!!! A skilled project manager will know this and create realistic plans with enough buffer in so that they can absorb inaccurate estimations and unforeseen issues. To do this, you need to think laterally and strategically i.e. trying to identify the worst case scienario.
Furthermore, helping stakeholders define their project scope is HARD since many do not know what they want. A skilled PM will help manage stakeholder expectations by using techniques such as MoSCoW to help them define the project scope.
Finally, and I will say this again, team building is crucial to delivering a project on time. I have worked with developers who were total primadonnas, act as if they know it all and that has created serious project risks not only for me but their colleagues when there is dependency from them carrying the mind set ‘I know best, and it will be done when it is done’.
If you think management is simple, and are struggling to deliver work in a timely manner, I am questioning your management skills and if you are any good.
@SS I’m not debating that it is stressful. It is, because things get behind, and you are absolutely correct on the estimates. They are not right, but let me ask you, how do you know how much they are off by? and if the PM beside you was running the project would he say they are off by the same amount? would they even be close to the same? I doubt it. What does this tell you about what you are doing? To me if you want to be accurate it means you are using your experience in knowing the team, the customer, the product, the delivery mechanism, your own process, the customer expected quality. Countless devlopers do not include QA, but instead of you padding the estimates, why not get the developers to provide the better estimate. Because you know what else happens, finance is padding the budget because they think you will need more. Everyone is padding everyone else. Why not have one version of the truth, fully documented? I’ll answer that, becasue everyone thinks they need to add value, where what they should be doing is documenting the process, the inputs, ascertaining basis for risk, etc. one version of the truth.
And so you know, one of my projects won project of the year a couple years ago, for the 400 miillion dollar company I work for. Why? improved margin,and customer satisfaction. Was it on time, no. So am I good at what I do, yes. But do I think I am overpaid for what I do, yes. You do bring up a good point about why do companies pay for PMs. I think this goes back to my earlier post. People dont come through on their commitments and are not held accountable so they need someone to essentially continually tell them what is wrong and possbible ways to fix it. Be the messenger with bad news, confidently. Not an easy job in that context, I just dont think it is complicated. Stressful yes, because not everything is in your control
I think I started to realize I the PM role was perhaps a little to overcomlicated when I was doing the PMP prep course awhile back. One of the questions was along the lines of. You are making a presentation to stakeholders which will result in a major decision. Ten minutes before the meeting your team lead tells you one of the numbers is wrong. you
A) change the presentation
B)reschedule the meeting
C) give the presentation and tell the stakeholders the error
Cant remember what D was.
anyway I think I indicated A.
I was told this is wrong, it should be B, because the the stakeholders time is important and you shouldnt be giving them wrong information. I then asked, what if the question was changed to 1 hour before the meeting,5 hours? 1 day? At this point the instructor told me that there wouldnt be a question with other times. I said why not. And then she could not answer. I said let me tell you why not. Because no PM would make a decision on the information provided in the question. The first thing the PM would do is determine the IMPACT of the wrong number.
But there a significant number of PMI questions are this type of question, where no one would actually do any of the answers without some more information. So why do they put these types of questions in? IMHO to ensure people do not get 100%. In other words, they are trying to make it more difficult that what they have written down on paper. It is PMI legitimizing itself by making the test hard
@JAN
“To me if you want to be accurate it means you are using your experience in knowing the team, the customer, the product, the delivery mechanism, your own process, the customer expected quality. ”
“Countless developers do not include QA, but instead of you padding the estimates, why not get the developers to provide the better estimate. ”
This is my point, delivering projects well is not a skill but an art. Yes, being a developer is technically harder and nobody will argue with this, but not everyone has the analytical, organisational, leadership skills to be a good manager. When I was a developer, I once worked with a technical lead who managed a product, he was technically good, but had a hard time prioritising work, controlling the scope, and motivating the team so that they worked efficiently. Whenever there were conflicts within the team, he was not diplomatic enough to handle the situation properly. If the conflict involved him and a member of the team, I remember his approach would be to take that person straight to a disciplinary hearing (worsening the situation) instead of looking at the existing delivery process, understanding how that conflict came about in an attempt to try and avoid it in future.
To build on another point you have made, a good project manager is detail oriented, devs do not have to and are expected not to know about of the whole project lifecycle, all they care about is can x requirement be technically done or not. This goes back to my point of why project managers are paid well given it is their plan based on the overall picture that the project team is following. If the PM gets it wrong, they are held accountable not the developers.
When I have worked on projects, there are multiple teams working on large scale projects, not just developers, because of that there are dependencies meaning that this is a team effort. Somebody has to manage that process well building on the point above.
You also keep coming back to the argument of project managers not delivering what was originally promised, therefore not doing what they are there for. At the end of the day the scope is defined by the stakeholder, if you are able to descope the project – which requires negotiation skills – then you are doing your job and I don’t know why you are complaining.
To conclude, the stress alone justifies why it should be well paid. The reason why it is stressful is because the role comes with a lot of responsibilities. If the PM is in control of budget and resources, it is their decision making in the end that will have a direct impact on whether the company makes money or not.
@SS, I’ll admit I am lucky to work with great professionals, with no real HR issues. No one has ever tried to sabotage my projects So you have a good point there, but that is more HR management than something unique to project management(still part of PMing, yes). I’d ask you though, how is this any different from the crew leader at McDonalds. He/She needs those same skills
So I think we then agree that simply having a PM does not mean the project will be on budget, will deliver the original scope, or be on schedule. So for all those that blame the engineers for not planning, please stop doing so. At the end of the day it is the engineers that tell you the estimates and the dependencies, which is essentially the plan. I once was given a piece of a larger project to manage. Very simple. The main project manager kept asking me for updates. I said to him, why dont I just update your schedule once a week and then you can stop asking, and I will make sure I tell you if resources dont show up on time, so you can escalate. But he didnt want me updating his schedule. So I would copy out his schedule, update it and then send it back. Useless time, and that is what I find a lot of project managers spend time doing, moving paper. I also once came across the pure textbook project manager on the customer’s side (we were delivering to their specification). This is all he ever did every week and it turned out great for him
1. Ask for status updates from his engineers and us
2. If not on track, get everyone in a room to determine why not.
Once a reason is ascertained, then ask who can fix it. Then escalate for this persons time. Also ask why no one told him about this dependency
If the problem is with the Vendor(us) ask if we can recover the time, if not escalate it with our management. If it is debated as to if we should do the work or them, we both search through the table of compliance. Then we argue if line item x in the TOC actually means what needs to happen now to fix the problem. Or we get blamed for not telling them every single detail. If no agreement on cost or scope, escalate
3. update schedule
repeat steps 1 through 3 every week
It’s just not that hard because the PM never has an answer to a problem. It is just the same methodology over and over again. Get more resources, escalate. Keep track of money do your forecast and tell people when you are going to run out and perhaps not be able to deliver on scope. Notify stakeholders
I should write a song. Maybe I’m just bored because I have been doing it for ten years.
But I do agree it is stressfull, or used to be for me. It is less so now since we moved to a model of not controlling the resources. I just tell upper management if I dont get person x by date y, schedule will slip. And if person x wasnt in my original request, I just state the documentation in order for me to solve my problem was insufficient for the other resources on the team to fix the problem, or this needs to be done because of product defect Z(we own the product we deliver), please have the product group fix this problem and then I dont need person X. This is my point, the reason things are late is rarely because the PM did or didnt do something something.I’ve never heard a PM say, it is late because I didnt do xyz. Projects are late because of the technical difficulties or a problem out of the PMs control (once again because he controls very little) He or she just follows the original three steps I posted. Back to my example, …upper management escalates my problem to the product group (if it is a product issue), and they then ask, which product defect would you like us to fix, because we are already fixing these escalated ones over here. Around and around it goes. At the end of the day it is about escalation once the planned resources cannot make the plan, scope, budget. And in my opinion, this is not difficult, stressful no doubt about it, but not all that difficult. And it is why I see it more as project administration, than management
@Jan
“@SS, I’ll admit I am lucky to work with great professionals, with no real HR issues. No one has ever tried to sabotage my projects So you have a good point there, but that is more HR management than something unique to project management(still part of PMing, yes). I’d ask you though, how is this any different from the crew leader at McDonalds. He/She needs those same skills”
You can’t compare both, digital management requires someone to have some technical knowledge to be good at it. Of course there are PMs who don’t, but it goes against them with devs putting wool over their eyes. I don’t code anymore, but the technical grounding gets me out of jams.
People management is hard, yes indeed you are lucky that you have never worked with primadonnas, I have, do you know how stressful it is when you are working with egotistical stubborn devs who do not listen to you and threatening to derail your project?
Descoping projects can be tricky too, what if the stakeholder is stubborn??
Yes, technically PM is not as hard as coding but at the same time it’s a hard job with a lot of pressure and stress when things are not going well. When a business hires a PM, essentially they are expecting them to deliver the project in a timely manner within budget. Good PMs can. People who are not very good at it will not causing the budget to go out of whack.
@SS:
“People management is hard, yes indeed you are lucky that you have never worked with primadonnas, I have, do you know how stressful it is when you are working with egotistical stubborn devs who do not listen to you and threatening to derail your project?”
Project managers are not supposed to do people management, as a general rule this is not their duty and most of them don’t do it. People management is the responsibility of the line managers to which the employees report to.
If the project manager thinks that there are issues with some employees working on the projects they manage all they have to do is to escalate the issues to the real people managers.
Project managers don’t bring value to companies by taking decisions but by identifying what decisions have to be taken and finding the appropriate people that can take those decisions.
For instance technical decisions on a project are not taken by the PMs but by the technical experts, PMs however have to find out what technical decisions have to be taken and ask the technical experts to take them. It is not their job to question those decisions but they have to understand them and see how they fit into the project and perhaps discuss them with the project sponsor and/or management so they can decide too.
“When a business hires a PM, essentially they are expecting them to deliver the project in a timely manner within budget. Good PMs can. People who are not very good at it will not causing the budget to go out of whack.”
Perhaps some companies actually expect this from their PMs, but in most cases the PMs don’t have the ability to deliver the project on time and on budget. That’s because may things are beyond their control. At most the PMs can help the company deliver on time increasing the chances for success but by no means good PMs can deliver on time and on budget just by using their project management expertise.
Good project management helps a lot but it does not guarantee the success. We must not forget that it is the team that actually delivers the project and not the PM. The skills of the team members are equally important if not more important than project management. Not to mention other factors that are beyond the control of both the team and the project managers.
Even if you have the best PM in the world and the best project team your project can still fail to deliver or it could end up delivering things that are not needed if the organization’s management does not do its job well.
@Adrian83
“Project managers are not supposed to do people management, as a general rule this is not their duty and most of them don’t do it. People management is the responsibility of the line managers to which the employees report to.”
Wrong, wrong, wrong, wrong…well depends where you are working.
Where I am currently working, a well known billion pound company, I am actively doing this as well as identifying issues and risks to senior management. That part is true in your assumption.
Yes, the developers I am managing direct line lead is the technical lead, but his role is strictly down to making/signing off technical decisions and is not involved in managing his team during the life cycle to delivery. Effectively the way it works is where he lends me his resources and I manage them directly. In other words, I create the delivery plan, and they all follow it. Easier said then done when you have egos in the team. Also the fact that they are all following my delivery plan means that I am accountable if the project fails. This is why the job is hard.
“If the project manager thinks that there are issues with some employees working on the projects they manage all they have to do is to escalate the issues to the real people managers.”
Ironically, we have an issue with the technical lead who is generally unreliable.
How do you mitigate that situation??? There are 2 approaches, escalate immediately to senior management, or deal with the person directly and try to get them back on track…This is the headache I have to deal with on a day in and day out basis.
“Project managers don’t bring value to companies by taking decisions but by identifying what decisions have to be taken and finding the appropriate people that can take those decisions.”
Wrong.
Projects I am delivering follow my strategic delivery plan, which is signed off by head of delivery and product owners.
Yes, I have to create a gantt chart.
Yes, I have to set up the meetings and make sure everyone attends dealing with impediments as they arise to keep the project on track.
Yes, I have to deal with the headaches that comes with managing a cross functional teams. People complaining, going on annual leave, being sick etc.
“For instance technical decisions on a project are not taken by the PMs but by the technical experts, PMs however have to find out what technical decisions have to be taken and ask the technical experts to take them. It is not their job to question those decisions but they have to understand them and see how they fit into the project and perhaps discuss them with the project sponsor and/or management so they can decide too.”
LOL this is exactly why developers don’t make good PMs, they are not lateral enough in their thinking. The technical side of the project is one important part of delivery, what about requirement gathering, documentation, planning, visual designs, getting resources available to you to work on the project?
Indeed, I am not involved in technical decision making, techies are, but again, they are following my delivery plan and timeframes. From my side, I have to make sure that you have all the information available to make the correct tech decisions.
“Perhaps some companies actually expect this from their PMs, but in most cases the PMs don’t have the ability to deliver the project on time and on budget. That’s because may things are beyond their control. At most the PMs can help the company deliver on time increasing the chances for success but by no means good PMs can deliver on time and on budget just by using their project management expertise.”
As much as it is about delivering work on time and within budget, it is about helping the business identify and deliver value. That is stakeholder management. Also, I have in the past delivered projects on time, not EVERY project is going to be delayed, it happens of course, but it probably would be less of a delay if someone with no PM experience was delayed.
“Good project management helps a lot but it does not guarantee the success. We must not forget that it is the team that actually delivers the project and not the PM. The skills of the team members are equally important if not more important than project management. Not to mention other factors that are beyond the control of both the team and the project managers.”
A good project manager will be skilful enough to facilitate the process, and very often it is the their plan the team is following to get to the end goal, delivery.
Sports is a good example, every sports team has a manager, they are not actually on the court playing the game, the players are, but they are giving instructions strategising the game with the team. Without a manager, the team will be disorganised and may not work together to win the game. That’s the value a good PM brings, they keep projects in control and get otherwise individualistic egotistical people to work together to hit a common goal. Team building is hard, you see it all the time in sports, teams with superstars underachieving in contrast to teams that do not have them.
Results don’t drop from the sky. It requires planning. All my projects were successful in delivering the required quality results within the time frame.
right, you must have projects with no people, no customers, unlimited budget, and no fixed timelines
i.e. your project must be you living in the woods, and your project is to find a tree every day maybe every other. And every day you find one. Hopefully there is no fire
Just came across this blog because I am little disillusioned with project managers. I was previously project manager with technical and business background working my way up to PM. In my current and past company, I am seeing/saw an increasing trend to promote executive assistants, PAs into project managers and scrum masters. This gives new meaning of glorified secretaries. Wonder what people think about this? Seems like increasingly companies see PMs as co-ordinating role which anyone can just do. Don’t worry you don’t understand the technical details of the project, what you are delivering and whether stakeholders are telling you the truth…seems like just as long as you can co-ordinate and take minutes you are qualified for the role. Those PM certifications are so easy to get, spend your dollars and a few days and you are all set to be a PM. Sadly I see a demise of the project manager.
Yes it appears that many if not most of the organizations today expect their PMs to be just some sort of coordinators and facilitators rather than real leaders or real managers.
In all the large companies on which I have worked PMs were not even real managers but peers to the project team members. It is not uncommon for some project team members to be more senior and better paid than the PM.
Being a project manager in many companies is just a job like any other job it is not a management position. Most PMs are not higher on the corporate ladder than the team members that are working on the projects that they manage.
Since the PM is not a higher position obviously a lot of people can be appointed in this position.
I don’t want to offend you in anyway but since the role of the PM is more about communication, facilitation and soft skills some executive assistants or secretaries can be better suited for the job then some good technical experts. Don’t forget that the PM is not a technical leader.
A former executive assistant that has become a PM would not be able to take technical decisions on the project but would just facilitate the decision process helping the technical experts to take the best decisions. The technical leader in this situation could focus entirely on the technical issues and don’t be bothered by other things.
@adrian83
Coordinating work and dealing with people is a skill in itself that not everybody is good at. It is not easy either, especially in highly political corporate environments where you have to deal with many stakeholders and have to protect the team from external interference which often leads to dealing with and resolving conflict. One of the challenges I face daily is with stakeholders trying to overload my technical team with work, a weak project manager will not know how to push back and be walked over. A good one will push back, and in the process gains respect from the technical team. This part of the job is extremely stressful, many difficult conversations take place.
I have met many technical people who behave as though it is easy to do this (like yourself), they also happen to be the worse managers blinded with arrogance. Yes, they can make *technical decisions*, but they lack the interpersonal skills to build a strong cohesive cross functional team that is optimized successfully. One of the challenges that comes with optimizing teams is trying to get different personalities to work together, improve their ways of working and resolve conflict.
There is a lot more to the role than delegating work, good project managers shape and change the operating model of the business for the better. To do this, this requires commercial understanding and the ability to use metrics to influence change. I am regularly analyzing the reports in Jira to identify bottlenecks and proposing better ways of working.
Finally, and this is why your comment is annoying, when things are going wrong it is the PM that turns into the scapegoat, making the role extremely stressful and high pressured. Hence, why PMs are well paid.
Your post is offensive and you just sound like a typical arrogant technical guy, who thinks that the only skill needed to run a business is being technical ignoring that it’s soft skills which is the key to getting people to work together as a team.
@SS
I just tried to explain to @Sasha7 why secretaries and executive assistants could be good candidates for project management roles.
I met a former secretary and executive assistant that had become a PM and was managing engineering projects. She was very good at it. Of course she couldn’t manage the engineers ( they had an engineering manager) as she lacked technical knowledge but she was managing the operational aspects of the engineering projects very well.
In my opinion the biggest strength of a PM is not his ability to plan the work of others (this is something that is not very difficult) but his/her ability to influence people without having authority over them. That’s in my opinion the real hard part of project management.
A PM needs to get senior managers, customers, functional managers and technical experts to work well together and for this strong communication skills are needed. Secretaries and executive assistants because the nature of their work can develop the required skills for project management better than technical experts.
The problem is that many people mistake the project manager with a real manager or with a technical lead and have the impression that he/she must take the technical decisions and give directions to the project team members. Normally the PM is not the decision maker on a project but the one that facilitates the decision making process. This happens because in some cases the technical lead or the technical manager also performs the duties of the PM.
“Secretaries and executive assistants because the nature of their work can develop the required skills for project management better than technical experts.”
Although an important aspect of the role, there’s more to PMing than organising work. To avoid repeating what I wrote earlier, a good PM in digital tends to have a mixture of technical knowledge, organisational, problem solving skills, and is analytical i.e. using metrics to drive change. Yesterday for example, I was talking to a developer in the project team about a technical process that exports a file in JSON, which in turned helped me understand better what they are doing and how to mitigate a situation enabling me to keep the project on track. Do you think that a secretary could do that?
You are simplifying the role implying anybody can do it, when there is a lot more to it. I would go onto argue that the best PMs are basically former developers, that have strong interpersonal skills. In my case, the reason why have chosen to be a PM and not tech lead is simply because I find the operational side of the business more interesting.
Adrian, from reading your comments, what gripes me is how you seem to undermine the difficulty of the role. I actually would argue it is harder than being an engineer given the level of responsibility, pressure from all sides of the business to get work delivered well, consistently. Whereas all a tech lead cares about is making the right technical decisions, and that is it. This is why PMs are well paid, and respected. Good one’s have the power to influence not only people but how the entire business runs.
I agree that the barriers to entry in the soft skill professions for PMs is probably less for PMs than for engineers or developers. But those of us skilled PMs in a very small niche of the construction industry, specifically in our specialty of providing network infrastructure for end users, have to build systems for new buildings to provide the information highway and integration to users in every market sector. Some of us have been involved in this work since the days of the main frame and the Bell operating companies. We have had to keep up with the explosive growth and demands of business and government since those days and evolve the technology infrastructure worldwide to meet the ever changing demands of users. We continue to design and install the information highway wiring locally and beyond to include communications wiring, wireless systems, emergency systems, security systems, AV and digital signage systems that average users take for granted. And, unlike other MEP trades in construction we are the subcontractor’s which usually remain onsite at the very end of projects, through client move-in and beyond, supporting them as they acclimate to a new space or building.
In our world the PM is the technical expert, requiring the overall systems knowledge, solid interpersonal skills to bring disconnected parties together, financial management skills to deal with usually unrealistic budgets, and be able to provide value engineering ideas on the fly to meet changing requirements. Our goal has always been to provide subsystems for networks to support company/user network needs into the future for 10 – 15 years.
@SS
I have been working in IT in technical roles for more that 10 years but so far I have only seen just one PM that had a technical background. Also I have seen that in IT most companies don’t value technical knowledge when they hire PMs. Yes many technical experts may move to project management but in most cases this is not the normal career progression for technical experts. An engineer can progress from an entry level technical position to CEO without being a project manager. The role of the project manager is usually not an intermediate step from engineer to CEO. PMs however can also progress to CEO.
Project managers in large companies, in IT at least, have a career progression completely different than the technical experts. In some countries (like the UK and Australia) you can start your career as a junior project manager as your first job after you had graduated college.
I personally believe that PMs should have a good technical background but it appears that in IT most companies don’t think it this way. I believe that for many companies a wedding planner would be a much better choice for an IT project manager role than an IT technical expert. They want someone able to organize things and facilitate the communication between stakeholders rather than someone that can lead a team from a technical point of view.
These companies probably believe that since they have senior technical experts capable of managing the projects from a technical point of view then there is no point for the PMs to also have technical backgrounds. When both your technical lead and PM are good technical experts you may end with conflicts and since the technical lead is usually not subordinated to the PM this can lead to big problems in your project.
Could you please explain why so many companies from IT don’t value the technical skills when they hire PMs? I know this is true because I have seen it numerous times. Thanks.
@Adrian83
Yes there are PMs working in digital that are non technical and it makes their job harder. On the same note, there are many that have technical knowledge. I am one, and it helps me immensely when communicating with developers and managing stakeholders by accurately describing issues as they arise. I honestly would be lost if I had no technical knowledge at all. Sure, I’m not CTO/tech lead level in terms of knowledge but I understand the fundamentals.
Only because you have not met many, does not mean that they do not exist.
Contd.
As I said, I simply am not passionate about coding to go down the traditional developer > tech lead > CTO path. It’s boring, that is why I am a PM, since it’s less about choosing the right tech but more about delivery.
@adrian83
Contd.
Like other soft skill professions; sales, marketing etc I will agree that the barrier of entry as a PM is easier than being a developer. But like every profession there is a huge difference between those that are good at the role and those that are not. Good PMs also tend to have a technical background (I do) to enable them to communicate better with the technical team.
1. This is absolutely hilarious!
2. PMs have always been in high demand across multiple industries with high compensation, investment in training, and career paths to Director or VP positions, so it blows away the silly argument that it’s a role that is undervalued and not respected– this dude didn’t know what he was talking about
3. It’s not shocking that the harshest critics are overconfident developers. In my experience, it’s these *sshole devs that don’t respect PMs and cause conflict— often intentionally. That being said, it’s a small number of haters compared to the entire cross functional team that highly respect and value PMs: E-staff, QA, Marketing, CS, Tech Pubs, Supply Chain, Legal, Finance, Third Party Partnerships, the cool devs, etc. The best way to navigate these dominant behavior types is to counter their aggression with facts. You’ll often find the brightest devs know nothing about the admin tools (e.g JIRA) or can’t even update a ROI sheet. Thus, that’s usually the point the PM becomes their best friend.
4. Lastly, the best PMs are great listeners and data gatherers so they have the facts when reporting to the e-staff. They are also great speakers and know how to get right to the point to get to decisions quickly. You know you have a good PM if emails are concise and meetings are shorter/less frequent. Inexperienced PMs make the mistake of scheduling meetings when all they needed to do was talk to a few people offline. Good PMs also shield the teams from bureaucracy and politics they don’t need to be concerned with. Establishing a solid PLM to plan future projects should be lightweight in concept and heavier in resources and time entering definition.
Ever heard an orchestra warming up? That’s essentially what you get with a bunch of experts all doing their own thing in their own way. Of course John Williams can’t play every instrument in the orchestra, nor can he do so as well as each individual – but he knows how to pull it all together so it’s not a big bunch of crap on “launch” day.
2019 the software industry is still very immature. When software hits launch day with the reliability of a car rolling off the production line, (that industry went through similar growing pains) then there’d be some credence in the objections of coders. Right first time, every time is possible. Until then put it down to lack of vision.
“Ever heard an orchestra warming up? That’s essentially what you get with a bunch of experts all doing their own thing in their own way.”
I loved this metaphor Eddie. Thanks.
Since doing a pure Scrum Master role for a couple of years, I can definitely say that teams can work in a self organised way to a certain extent.
Hence, some degree of Project management is required when team members need ‘reminding’ to do tasks and mitigate risks.
As a Deputy PM I find the distain we are held in very hurtful. A PM never switches off, and our social lives suffer because of this.
Essentially a project can simply not be delivered without us – end of story.
Many times I’ve thought about leaving this field due to the constant ridicule I have to endure on a daily basis.
“Essentially a project can simply not be delivered without us – end of story.”
I would argue with this statement. I would say that a project can’t be delivered without at least some basic project management principles applied but you can deliver projects even if you have no project management specialists on the project teams.
Only PMs that have no knowledge about software development or no knowledge about the domain in which the software is being used are ridiculed.
PMs that are knowledgeable about the things that happen in the project, they don’t have to be experts, are if not respected at least not ridiculed.
Unfortunately there are many PMs in IT and software development that understand almost nothing from the activities that are being performed on the project, every task for them being just a label in a document or in a project management software. These people get no respect indeed especially when they claim that they are leaders, mentors, etc. They are just purely glorified secretaries.
Developers only make fun of the PMs that are unable to have a basic pertinent discussion about the work that needs to be performed.
My opinion has changed since we last spoke. Agree with pretty much everything you say now.
Projects can be delivered by a team of developers but where a PM adds value is to support them to remove complex blockers (organizational). In a small company org impediments can be resolved without a PM, but enterprise orgs where you have several layers of stakeholders it is much harder – a good PM is skilled enough to be able to facilitate the right discussions and influence change working collaboratively with the team.
Hence, on that note, a PM should not be expected to be technical, that is a bonus. Commercial awareness is much more important for them.
Thank you very much for this presentation. It has brought me much light and provided me with knowledge in PM. I now understand and know the key fundamentals of the project management process.
Some points:
1. Yes, a group technical experts or developers *CAN* deliver any project left to their own devices. Will it be a quality project, within budget, or within acceptance criteria as determined by the business (operations)? Almost definitely not.
2. Are PMs needed in small projects? Yes, absolutely. Not to execute, but who do you think is training your business to provide enough descriptive detail that a developer can determine an acceptable solution? Who is reviewing the change request to make sure it’s not trash and worth your development time to begin with? Who is keeping ten more change variants all related to the first request from hitting the developer 2 days apart as not all detail was included in the first draft or approved change request? That useless admin…
3. The job of a PM isn’t to know every technical detail. Developers, your Vice President DOES NOT CARE WHY a project is behind. They care if it’s on budget, on schedule and if it’s northeast there’s a concrete plan immediately prepared to fix it, NOW! So while you say there’s no method in software development to always know how long something will take, it’s the PM running cover for you with that VP.
To whoever said they could do the PMs job in addition to their development role, I dare you to walk into your VP’s office with that entitled attitude and tell them you’ve got it handled. Your PM will breathe easier with you on the soup line.
Good PMs are why the business has to justify cost before something is sent for development. They’re the reason why developers only have to clarify 5 things instead of 100 on every request. PMs know what platforms the company can and can’t afford. And while the developers may know what the *BEST* technical solution is, it’s your PM who knows if your executive is willing to pay for it and the budget condition of the company.
There are some amazing developers out there. But the unbridled arrogance and hubris of many developers on this blog is obscene.
CIS and ENG majors are a dime a dozen. Given unlimited resources a trained monkey can deliver a project. But to do it well, quickly and efficiently is why PMs exist. This doesn’t need to be explained to strong high performance developers. So if it had to be explained to you, you’ve got some introspection to do…
Finally, a PM should absolutely have input into his team’s performance, whether that team is matrixed or direct report. Performance is easy to measure, do they hit reasonable deadlines that they often provided input into setting, and is the quality of their deliverables reliable and typically free from defect? If overly technical, I can always go to their line manager for collaboration.
But in this blog the developers who say estimates can’t be given, performance measurement by the PM is irrelevant and metrics are just for blame/shaming, these are the developers who want no accountability. Because deadlines missed, deliverables half assed and projects failed, when documented properly, result in turnover of incompetent technical resources, not PMs.
Think about that the next time a developer, any developer says documentation and approvals are a waste of time.
All valid points, but software development is moving away from traditional waterfall PM delivery to Agile now, where PMs no longer exist as a role.
Agile is one of several methodologies. It is not a silver bullet and has very specific uses just as waterfall does. The future is a hybrid philosophy that purists advocating for either pure waterfall or agile both miss the train on.
Project Management as a role is changing. The future of the PM profession includes machine learning, cloud and emerging technologies integrated into administrative tasks and leadership above even those. Read the below article; more likely is exactly what many devs in this blog fear, empowered PMs (good and bad) who are far closer to being decision-making leadership than peers to engineering or developers.
Technical resources (people for those sensitive to being treated as a number) will can’t oversee their own spend, direction or strategy of the business. They’re stereotypically too insensitive to budget, business and customer for that. Someone must always conduct the train (to turn an agile phrase). THAT is why there will always be PMs. The executives are too busy, and inmates can’t run the prison.
https://lnkd.in/eQuNkNT
“Technical resources (people for those sensitive to being treated as a number) will can’t oversee their own spend, direction or strategy of the business. They’re stereotypically too insensitive to budget, business and customer for that.”
That’s the Product Owner role in an agile environment, not technical development team.
“Someone must always conduct the train (to turn an agile phrase). THAT is why there will always be PMs. The executives are too busy, and inmates can’t run the prison.”
Mature agile teams do not need a PM, the whole point of doing agile is to have self organised teams, where a PM will become a bottleneck for that.
The agile events such as stand ups, retrospectives, planning, refinement are feedback loops to collectively enable the team to manage risk efficiently, where in contrast PMs will own and manage risk using RAID logs.
Furthermore, good agile team’s have a Scrum Master supporting them, whose role is not to own the process like a PM does, but coaches the team agile and agile best practice to give them the knowledge needed to apply agile practices properly.
Agnostic isn’t wrong. Too many firms are treating Agile like it’s the solution to all development and deployment concerns, it’s not.
SS, you argue the PO role replaces PM, but they’re not the same. A PO has to be in the trenches with the team by argument of Agile’s methodology. And to Agnostic’s points, Agile teams actively dodge making commitments they can be held too more often than not.
A PO in my experience is a dumbed down PM role that is told to focus less on the big picture and more on the technicals. This means your PO often doesn’t know the company budget, constraints, cross-functional dependencies your product management team in agile terms) and little accountability to try to.
You argue a PM isn’t necessary in Agile, I argue that PMs keep resources and the methodology honest and accountable; this is why ultimately Agile WILL FAIL. It has specific uses, but most firms use some adoption of wagile, and even pure Agile has failings that a cash-strapped firm or finicky customer can not afford.
Agile is not the answer to all ills, it doesn’t replace strong PMs and good project management, and I’ve been at a firm that introduced Agile as an excuse for IT to bypass and eliminate all PMs in the division. I then watched their spend spin out of control, accountability plummet and spent months sitting with executives explaining that developer lip service was precisely why that structure had failed. PMs back in, and suddenly there’s transparency again.
80/20 rule. At any given time 20% of your devs are doing 80% of the work (it’s a separate conversation that every developer thinks they’re the 20%). This means that 80% waste is present. A PM finds and reduces this imbalance. Left to their own devices, the building on fire, the company one dollar from bankruptcy, a development team on Agile will spend indiscriminately. Because the design of agile and the mindset of its supporters know no other way.
That’s why when you’re told to adopt Agile, the first thing they say is it doesn’t count unless you buy in unconditionally and fully. The only other methodology in the world that operates that way is organized religion. And it should be examined carefully and with great suspicion as a result.
Ah yes agile, the saviour. Feel free to google “agile” “fixed price” “fixed schedule”.
What do you find, not a lot, why? Agile makes no commitments, the only commitment they make is to spend the money. Works good for a software shop making a product with no paid for requirements, doesn’t work when there is a real customer who is paying for a set of requirements. I have seen it all too often, deliverable is late, or the deliverable doesn’t have all the features the customer wanted, or the agile guys on purpose make the requirements so vague, so they can weasel out of delivering them. If the customer asks for something such as the name field must have 128 characters, the agile guys reject that requirement as too detailed. In the agile person’s mind, they are allowed to decide how big the name field will be, because they must be smarter than the customer. and when the agile guy decides to split the name field into name1,name2,name3 for some unknown reason and the customer tries to write a report, he then realizes he must concatenate the names together and get pissed off, the agile guy says, oh you didnt tell me that you didnt want to concatenate, can I have more money?
show me an agile project which came in on the ORIGINAL budget, schedule and feature set and a happy customer
‘ show me an agile project which came in on the ORIGINAL budget, schedule and feature set and a happy customer’
Many waterfall projects get delayed too.
What’s your point?
At least agile is a lot more upfront with managing expectations as opposed to over promising and under delivering.
The whole point of agile software development is to not promise to deliver everything but be value driven, where the backlog is prioritised by value with high value backlog items priority in the timeframe allocated. This ensures that the clients more important requirements get done in the timeframe allocated.
If the whole scope of work hasn’t been delivered in the timeframe, and the Stakeholder wants additional work delivered then that is a discussion that the business needs to have with them.
‘ so they can weasel out of delivering them.’
‘Commitment’ is a Scrum value , mature agile teams adhere to delivering their work to meet goals.
‘If the customer asks for something such as the name field must have 128 characters, the agile guys reject that requirement as too detailed. ’
You can have detailed requirements in agile, actually, it is bad practice to prioritise anything in a sprint if the story is not ‘ready’ to be worked on, by that not properly understood by the team before being picked up. As part of that the business requirements is reflective of the clients needs and should be properly understood. This is the point of doing backlog refinement sessions.
Agile is not the silver bullet, you are right but it is a lot better than the alternatives when done well.
The reason why many businesses fail to do it properly is because they are poor agile practitioners, that are attracted to agile’s iterative delivery but lack the deep understanding needed to do it properly.
regarding this:
At least agile is a lot more upfront with managing expectations as opposed to over promising and under delivering.
Is it managing expectations? or is it setting no expectations?
I have seen both methods in my organization. all I ever see out of agile is, “we didnt get to it all”. so the PO or Product manager is constantly deferring. My two cents on the problem with agile: They leave the actual work until the end(because they dont want to commit a date until a point in which it is actually almost all done), then they realize they cannot do it all, or they have problems and have to delay. But they will tell you they never committed to begin with so they are not late. We just had a customer come unglued because they dropped scope at the last minute. What was our response, oh dont worry we will get that to you next quarter. IMHO agile is good for a brand new piece of software where customers don’t really know what they want, and want to pay people to create software and continue to refine.
In our organization the customers have to guess at what might or might not be delivered because there is no commitment. Sure this is refining the backlog for higher priorities, but would you want to live your life like you are in an Emergency Room triage, getting bumped and waiting. The difference in waterfall, is waterfall makes a commitment and adds resources to make the commitment…because it is a commitment. Do they always make it, no, but the PM is there to make sure they at least try and to bring it to management to get more resources. It is a fundamental philosophy difference. Try and deliver what your customer pays for, or “manage your budget to the highest value”. One is commitment focused, the other is budget focused. of course if you do waterfall poorly, you will go broke. If you do agile poorly, you lose your customers and then you go broke
A lot of orgs are not doing agile properly and it sounds like yours is no different.
It’s hard to do it properly.
“ In our organization the customers have to guess at what might or might not be delivered because there is no commitment”
One of the scrum values is ‘commitment’, where the expectation is for the team to deliver what they say they are going to deliver to meet a sprint goal.
If that is not happening at your org, the issue is a lot deeper and indicates a lack of understanding of how to apply agile principles and concepts properly.
Incidentally, with the above in mind, Risk management in agile is better than waterfall where if the team are consistently not meeting their goals that in itself should be a massive red flag. Unlike a waterfall environment there is a higher level of transparency, where this is seen sooner.
In a waterfall environment too because there is a single person owning the process – a project manager that can lead to a risk in itself, the whole process breaking down if they are not around.
I think you are correct in the PM not knowing the risk, and this is a risk. I have seen this all too often that the PM does not know enough technically to know what is risky. And I think agile exposes risk better, but exposes it too late. i.e. when do you find out something cannot be done, once the sprint starts. So if this feature was schedule last, you have no room to move. Waterfall tends to schedule development in parallel, to try and expose risk earlier.
However your statement: One of the scrum values is ‘commitment’, where the expectation is for the team to deliver what they say they are going to deliver to meet a sprint goal. is true, but ONLY at the sprint level. This is the crux of the problem with agile is how agile schedules things. Waterfall schedules requirements, development, testing, fixing. The waterfall team schedules amount of calendar time for fixing based on history. Once waterfall is done testing, they then try and acquire more resources to meet the fixing schedule.
Agile doesn’t seem to ever schedule the fixing part of a schedule, instead believing the planning and setting of scope is so good nothing will go wrong, but when they realize they cannot do everything, they start dropping scope. It’s almost like dealing with a “Father knows best” philosophy. Like I said its great if you have no actual customer paid for features, as it allows you the flexibility to build what you want, or when the requirements are not understood. What I dislike about agile is telling customers they cannot put down detailed requirements, as that is “up to the developer”. Ultimately for agile to work very well in a customer paid for feature environment, every single possible use case the customer has needs to be documented. But once you do that you are basically part waterfall.
which goes back to someone else’s comment “Wagile”
No where in the Scrum guide says ‘Commitment’ is exclusive to sprints.
Rather, Commitment is a way of being and thinking.
To forward plan, Backlog refinement sessions are used to do this.
It sounds as though you have not worked in environments doing agile properly.
you could be correct. The bigest difference I saw between the two methods, is when things went south in Waterfall, the organization went and got resources to make the commitment. In agile, it seems the philosophy is to drop scope rather than to get more people to make the commitment. And maybe that is more our organization than the agile process. It seems agile for us, by the time they know it is going south, more people cannot help because it is too late. It’s a little scary here, they are doing development two weeks before a release. In waterfall devlepment ends months before a release
I would like to think that I am correct, I’m a qualified Scrum Master with over 5 years experience.
A good agile team has a product owner that has a roadmap, and various other reporting to help them organise their backlogs
you may know what you are doing in your organization, but that does not mean it applies to all software development. I am simply stating that agile does not work as well for customer funded fixed feature, fixed schedule, fixed price contracts, compared to waterfall, IF the feature specification is known.
You have not stated if that is the type of work your organizations contracts or if you are allowed to defer features/fixes with no impact. Or do you have something else going on.
I’m more curious than anything
I work for one of the biggest technology companies in the world.
Yes I agree might not work as well for clients. With that said Kanban is better for that.
Agile is better suited for Product driven environments.
“ Incidentally, with the above in mind, Risk management in agile is better than waterfall where if the team are consistently not meeting their goals that in itself should be a massive red flag. Unlike a waterfall environment there is a higher level of transparency, where this is seen sooner.”
That’s crap SS. Because Agile is working at break-neck page to execute on half defined user stories, it’s more prone, not less to introducing unexpected and unacceptable risks into the process. Waterfall is superior to a Agile at identifying risk, most especially in projects the Agile team hasn’t executed before. Pointing to a project manager as a single point of failure for risk is a trash cop-out, as in an Agile schema every individual of the team has potential to introduce risk, magnifying not reducing exposure.
It is a well accepted shift from waterfall to agile that failures will happen more frequently and potentially more severely, supposedly in exchange for more frequent delivery of incremental releases.
Agile performed by the book *can* be more transparent. It almost never is as is mentioned firms frequently do not execute agile with high accuracy or adherence.
DO NOT make the argument that Agile is both faster and safer; much like a car speeding down the freeway at 100mph , agile lets you get to your destination faster. Whether your car is in one piece, you followed the route requested, you burned the full tank of gas in the process, or if it was safer are far less certain and usually run counter. Risk to reward, speed to reliability, agile to waterfall.
Google ‘definition of ready’ – if agile is done properly then stories should always meet that criteria before being prioritised i.e. to reduce risk to the sprint goal, the necessary prep work needs to be done before hand.
As a rule of thumb all stories should have enough information in them to be sufficiently worked on without many change requests.
‘ Agile performed by the book *can* be more transparent. It almost never is as is mentioned firms frequently do not execute agile with high accuracy or adherence.’
I agree with this, a lot of companies are doing a bastardised version of it. Hence, if done properly, it works really well.
The ultimate goal of project management and planning is efficiency. You want to do as much as possible in as little time as possible.