Why project managers get no respect

There is not a child alive who dreams of being a project manager. Maybe a firefighter, a rock star or an astronaut, but not a project manager? Nope. There’s  something inherently dull about the words “project” and “manager”, the notions they generate make the flames of even the brightest imagination flicker and fade. 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 a programmer, 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 stereotype (ask at your next happy hour with non PM friends).

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 cool, high profile occupations 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 output.

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 D-Day invasion of Normandy, The construction of the pyramids, the Empire State building, or any of a thousand great things made possible only by someone’s effective management of the project, people think of pocket protectors, overdesigned charts, epic status reports, and people who spend too much time in rooms filled exclusively with other project managers. 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 (output).

The news isn’t all bad. This lack of respect creates a huge opportunity for people with open minds: their expectations of you are low. If you take the time to find out what it is that the people on the project need from you, or value from you, and make that as large a part of your job as possible, 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 PMs can do for a team – and you’ll earn not only their respect, but their trust and best work too.

171 Responses to “Why project managers get no respect”

  1. SS

    As a former commercial developer that is now a PM, I can say that Project Management is very tricky.

    As a PM, I have to manage stakeholder expectations, manage my resources efficiently by delegating work to the right people as well as coaching/motivating my team. I also have to deliver projects on time and on budget, which means that I once I have organised my sprints, and the project has begun, I have to make sure that my team is on track through daily stand ups, retrospectives as well as writing well written user stories and user acceptance tests.
    Outside of this, I have to develop a good understanding of what technologies are involved when delivering the project. I am not hands on in my role, but whenever I embark on a new project I actively help the dev team with choosing the right technologies, as well as helping them devise a good software architecture.

    I think this article is very unfair in its assumption that PMs do not play an important role in delivering projects because they do not do the actual grunt work. The work we do is arguably harder for the reasons stated above.

    Reply
    1. Junior Smith

      “harder” LOL. and I am sure your pick of what technology developers should use takes heavy weight in the final decision made by senior developers and architects. — Thanks for adding evidence to the above article.

      Reply
      1. SS

        No, I generally let them decide, I just like to be involved in the process since it will help me understand what is technically involved.

        Reply
        1. JK

          As someone who has worked on many IT projects, I find little value in PMs.
          They tend to be an overhead as they want to understand details, when they don’t need to know them. They like to control things, so it appears they have control. They want figures to present to the sponsor so it appears the project is going well, when the time it takes to gather these figures people in the project could be actually doing work. I’m sure there are some who are good but having encountered 30+ of them they’re all pretty much the same.

          Reply
          1. SS

            Well the PMs you worked with were basically useless. I was a commercial developer and after making the transition to becoming a PM, it is not as simple or irrelevent as you make it sound.

            If you are an agile PM like I am, you have to make sure the productivity of your team is high and to do that, I have to monitor their progress using burn down charts, burn up release plans, cumulative flow diagrams to work out their velocity. I was recently in a situation for example where I was managing a remote subcontractor on a project that basically did little work for half of the project (this was before I introduced the reporting). It was only after looking at the CFM I had to get him back on track. The point is if nobody was managing him, the project would be severely delayed because he was coasting it – this is exactly why management exists to prevent this.

            Outside of that to make the developer life easier, I have to ensure the functional spec document is properly broken down into well organised user stories, with the right story points attached to them.

            Sure the developer can probably do this, but if he is in the middle of a sprint, do you think he will have the time to do this? Do you want him to do this work, or would rather have him write code? Especially if there are several projects to manage on the go? Do you also expect the developer to deal with client requests too? In every software build I have worked on, the client always tries to chuck additional features that goes beyond the spec, which can potentially lead to scope creep.

            I am not saying that there are not bad PMs out there, often the good ones have good technical awareness like I have since I have spent time as a developer. Outside of that I actually spend a lot of time trying to manage the project correctly by motivating, improving existing processes so that projects are delivered smoother. But by making PM sound like a walk in the park it isn’t. If anything goes wrong the PM gets blamed. If projects are not delivered on time, it affects the company, since they are unable to invoice the client which affects cash flow.

        2. Adrian83

          For me it is always funny when I hear a project manager saying that he/she lets the team decide on technical issues. That’s because very often (almost all the times) the project manager is not the most experienced subject matter expert on the team (many times he is not a subject matter expert at all) so he simply has no other choice than letting the team (actually the technical leads) to decide on all the technical aspects.

          I often hear project managers saying that they are empowering the team, giving the team members “authority” to decide, but in reality they (the project managers) lack the competence needed to take decisions of technical nature.

          Probably many project managers don’t want to look dumb in front of the team members and instead of telling them that they are unable to take technical decisions they prefer to give the impression that they are actually giving the team higher responsibilities and the power to decide.

          The reality is that most project managers always want to be in control but the fact they are not the best technical experts on their teams severely limits their ability to control the project team as they will not be able to give technical directions to the team members.

          When there are better technical experts than the project manager or the project manager is not technical at all it is clear that the best subject matter experts on the team, and not the project manager, will take all the technical decisions.

          Reply
          1. SS

            You are missing the point of project management, the point of it is to help the team deliver the project on time and budget, not to be hands on with the code. Hence,it is much more heavily linked to operations as opposed to the technical side of a business. A PM might not be expected to write code, but they have to do a lot of administrative tasks – budgeting, resourcing (assembling the team for a project), QA, account management, internal and external reporting, keeping track of spirits (if running agile) using burndown charts/cumulative flow diagrams/resource management . In addition, if the project is going badly, the PM will be accountable not the developer.

            A tech lead is exactly that, a tech lead, they are expected to know technical side inside out because that is their role, and very often they are the one’s doing the hands on dev work too – which is what they should be doing, not being involved in the operational side of a business.

            For the record, I can code, have a computer science degree and spent time as a commercial developer. Having technical awareness helps, but the reason why I made the switch is because programming is a boring job where your life is coding a set of requirements as opposed to being involved in the bigger picture.

          2. Johnny T

            That is how it is supposed to work. Now if you are working on a huge global project I mean involving multi components from design, infrastructure and global implementation and major capital expenses your program and project manager would own you! You are a technical authority at best and though an important component to a project not the only one.
            on such projects a project manager is engaged pre-sales at the bid stage and is often involved in bid management to workout costs and high level time plans. On such a project your line manager would understand that YOU report to project management for the duration of you allocation to a project. You may be a shared resource but in large projects you can also be a dedicated resource and you performance on that project evaluated by a PM can propel you in a corporate structure or see you dismissed.
            Honestly, reading into what you stated shows me that you do not have such experience, your mind is simply technical.
            One issue never covered is the over use and misuse of project management especially in the IT world. Just as there is more misapplied in vogue methodologies then properly applied. The PM who mentioned he was an Agile project manager is suspect to me. I have seen that applied to everything it should not be. I have seen it create more overhead for everyone. Issue is that Project managements management (got that) often is placating purely political whims and in turn requests all kinds of info from a PM and then the PM ends up actually interfering with project progress in order to gain the required info. Info that is often so dynamic that it is useless by the time it MIGHT be looked at. Most of these IT projects that have PM’s assigned need no PM. Only complicated engagements should be so managed. NON-Cookie cutter, high dollar Million +, with multi phases. Rollout of a repeatable deliverable at few hundred thousand per does not qualify! in addition the creation of a small e-commerce web site does not qualify, lead engineers can handle this. THIS IS THE PROBLEM.

          3. SS

            Thanks Johnny for calling me ‘suspect’, admittedly I am not the most experienced agile PM since I have just started doing it, but I work hard to do my best in implementing agile in my company as a PM. I am also a certified scrum master.

            From what I can tell you, when this company (a small organisation) didn’t have any one managing their in house product or other projects using a framework, they ran into the following problems:

            1) Nobody to manage unrealistic stakeholder expectations. (big problem)

            Developers would often be given unrealistic targets by the stakeholder i.e. You have 1 week to deliver 4 weeks amount of work not taking into account what is actually realistically possible, since velocity wasn’t tracked. This also was bad since it doesn’t work well with changing requirements.

            2) When working on meeting a target, the developers would then be interrupted by change requests causing a lack of focus and rushed work as opposed to properly completing functionality one at a time and releasing the product in increments.

            3) Poor quality work being delivered – rushed.

            4) Developers who have to spend time doing administration work; internal reporting etc rather then focusing on writing code.

            5) Nobody tracking productivity properly. I use burn down charts to do this based on the velocity of my team during weekly sprints.

            6) Sales team taking on work with impossible time frames and lack of resources. Since coming into this role, I have told the sales team to think agile, that means not letting the customer disrupt sprints by asking for work to be done straight away, but to wait for the next sprint cycle before undergoing their work.

            7) No QA process based on user acceptance criteria in user stories. Nobody to ensure that this was being done properly, previously developers were doing this, we now have a dedicated QA tester doing this.

            etc etc etc

            As a result of the above, the original product had to re-written by my team. It was no maintainable (very hard coded). The company now has a working product which scales.

            As much as Project management is useful in large organisations for the reasons that you have mentioned – and I agree with them. In start ups or small organisations (the organisation I am working in), poor project management can lead to a poorly executed product which could cause the start up to fold. Telling your tech lead to project manage business critical builds, when resources are already extremely tight and you want him to code is going to slow delivery down.

          4. Your Boss

            I am a Project Manager. Prior to moving into project management I was first a .NET Developer and Solution Architect. I’ve implemented large enterprise systems for the Federal Government as a Developer, Architect and PM. In a pure product development environment, PM’s certainly have a reduced value; however it is now 2016 and the client service industry exploded years ago; in this world PM’s are beyond vital – more important than the rock star Architect on your team and now as a Director I would fire the Architect before the PM 99% of the time. As a PM, I was no doubt smarter than most of my Architects and can guarantee in client services the PM’s job was far more difficult and vital. Any technical experts that disagree, it’s simply because you are so short sited and buried in code that you think the world is made up of 1’s and 0’s – do yourself a favor, go thank your PM for inflated salary and growing job demand – he’s the one driving business for your company in a highly competitive market.

          5. SS

            Agreed.

            Making sure projects are delivered on time, with high profit margins affects cashflow and client retention. This does not require technical skills but business acumen if anything. The developers on here moaning, are as you say extremely short sighted and need to spend time delivering projects. By that, managing a cross functional team trying to keep everyone motivated and on track.

  2. Bob Barnes

    Just to summarize, project managers are essential to any project and they play a critical role in delivering projects on time and on budget. The best type of power project managers can use according to PMI is the Expert power ! If you have knowledge in the field, you will get the most respect from your team.

    It’s funny sometimes to see job descriptions where employers search for candidates with degrees in journalism or communication !!. Even project managers spend 90% of their time on communication I believe that having a technical background would add extra respect and improve cooperation with your team which is a key to success.

    Reply
    1. underrated

      If they do budgeting, why do they put their nose into calibrating employees? Huh? What do they know? Really, what do they know?

      Reply
  3. Jane

    A majority of the PMs i work with don’t understand anything about the projects they manage. They put in the minimal hours. They take vacations during critical deadlines and are hardly ever available to answer questions about their projects nor resolve problems with the their projects. At crunch times,with limited resources, they are unwilling to put in any time or effort to assist the team.

    That being said i also have worked with amazing PMs that have been there through the entire project. They knew every little detail about their project and were always available to answer questions or help resolve problems.

    I would say that a majority of the PMs i have encountered deserve little respect and are lazy and ignorant. The few PMs that have earned my respect have not received the recognition that they deserved.

    Reply
    1. Lee

      Oh for fucks sake, does this topic really matter? None of us are experts, irrespective of what talents we think we have. We’ re all doing the best we can, but ultimately we all do better when working together. Job titles are so last century.

      Reply
      1. underrated

        Yes I would tolerate the PMs’ presence if they stayed away from calibrating employees and giving them a performance rating. Why don’t they stay away, and we would tolerate their presence like we tolerate the presence of non engineering staff like janitors, coffee machine cleaners, etc. Oh wait, but they actually do useful and arguably indispensable things, but they don’t take part in calibrating engineers…

        Reply
        1. S

          Just like a sports team does not has a head coach?

          Like it or not projects need PM, without anyone managing a project there will be nobody to ensure that people are working efficiently enough so that the project is on track to prevent delays. That is the nature of commercial programming I am afraid. A good PM would also mentor and coach his colleagues with some technical awareness. They often also deal with client requests and since the client is setting the scope this is essential to the management part of the project – something that the dev team does not do!

          Reply
          1. Adrian83

            To some degree project management is required in any project, that’s true. However in IT there are also a lot of small projects (many with a single person working) that don’t require much project management and using a dedicated project manager would be just a waste of money with virtually no benefit.

            For example I have seen projects in which a company for example wants some new features for an existing application and for that it contracts another company that does the work using a single employee. That employee is typically a technical consultant who talks to the users identifies the requirements determines what needs to be done estimates the effort, does the planning and finally the actual work. This employee also reports to the customer the status of the project.

            In this scenario the company that does the work is typically payed by hour and the time needed to complete the work is being estimates by the consultant and approved by the customer.

            While this approach may not be applicable for larger projects it makes perfect sense for smaller projects and demonstrates that a professional project manager is not always needed.

            A couple of months ago I met a person working for a very large corporation that was about to start such a one man show project for a customer. I specifically asked her if there is going to be any project manager involved and she say no as she will do by herself everything that is needed to deliver the project.

          2. SS

            The whole flaw in your argument is that there has to be somebody has to manage the ‘technical consultant’.

            If there is no PM managing them, then it will be the client. Do you think that the client has the time to manage their day to day activities. Has the time to (if following agile) to produce release burn up reports to work out if their velocity is in line with when the project should be released. The other advantage of having the middle man, is that the reporting will not be fudged but accurate.

            Also it is all good with saying that “This employee also reports to the customer the status of the project.”, what happens if this employee (sub contractor) disappears mid way through the project, who is going to chase them up – the client?

            Finally, good PMs do not let the developer do all of the requirement gathering, they do it with them. They have several meetings discussing on a high level what the client wants. They then write a functional specifications document, where every requirement is clearly broken down into user stories, with acceptance criteria’s which is then approved by the developer and the client. This saves the developer a tonne of time, since all they can then focus on what they do best, and is getting on with coding the product. If there are any problems during the build of the product i.e. client wants changes, the developer doesn’t have to worry about talking to the client, since the Project manager does that for them. Hence, the project manager ironically needs to know the project inside out to do this!

            I recently managed a single sub contractor in this set up.

          3. Adrian83

            @SS

            Well the technical consultant can manage himself very well as long as the non-technical aspects of the project don’t take too much of his time so he will not have enough time to do the actual work. I have worked as a technical consultant and it was my task to gather the requirements from the customer figure out what needs to be done and then do it. I didn’t need someone such as a project manager to tell me what the business users had already told me.

            Now if we are talking about a project that implements a new software solution then yes you need some people to manage the operational aspects of the project, gather requirements discuss with the business users about what needs to be done, report, do administrative tasks, etc. Technical people usually can’t manage these things because they are too many in these kind of projects and they wouldn’t have time to focus on the actual work if they were doing those things. In addition, many technical people may not have the right skills for this.

            However, after the project that had implemented the solution had finished there will be usually someone to support the software and fix the defects that inevitably will be discovered. While using the software the users will usually also discover that they would like additional functionality or something changes in their business processes and additional features are required. Some companies include in their support and maintenance contracts the ability of the customer to add new change requests to implement new features. There is usually a system where the users can log both defects and enhancement and the developers or the technical consultants work on both, defects having higher priority. In this way software development can continue outside the scope of a project and no project manager is needed.

            The new features may be implemented also as part of small projects, which are basically a set of change requests for which an IT professional or a very small team commits of doing usually for a fixed budget. In these cases, there are very few project management issues and there is no need for a project manager to work full time. If a project manager is used for these kind of projects, then he/she will have to work on several such projects simultaneously in order to fill his/her time. Small companies may not even have enough projects to keep the project manager busy full time so they don’t hire one. Although this doesn’t happen to often even larger companies may choose not to assign project managers for their smaller projects in order to reduce costs.

          4. SS

            Adrian, if the project is very simple, say for example the project is to deliver a 5 page static WordPress web site, then you are right, the client can get away with not having a Project Manager and just work directly with the ‘technical consultant’.

            However, if it is a serious product that the organisation is building, or there are a series of projects that need to be delivered, then the organisation defiantly needs a trained Product or Project Manager, especially if there is a cross functional team assembled to achieve this. Developers, QA testers etc etc Somebody has to manage them.

            Likewise, there is also a lot more to getting work delivered then using a ticketing system. Somebody has to manage the ticketing system for started, by first talking to the client and finding out what is high priority and what isn’t. Letting the client open tickets is a really stupid way of doing things, and the Support and maintenance team should NOT be accepting tickets that are full blown features without a face to face conversation. Since, very often full blown features is often a pre-requisient to a new version of the product, where a new version product road map needs to be documented by writing really well thought out user stories with acceptance criteria. If you do not do this, you risk the developers implementing useless functionalities or even worse creating functionality that is not how the client wanted it.

            Also expecting the developers to do the admin side is a poor a way of managing any project. A good project manager will not let them do any of this, for the sole reason that their strength is coding. Many developers that I have worked with are happier with this set up, since it means that they have less work to do and can focus on their ‘sprints’ (I am an agile project manager)

            Finally, having amazing technical skills does not make you a good project manager. When I was a developer, I worked under ‘tech leads’ who were absolutely useless at management. For example, the one that comes into my mind right now was absolutely useless at resource management (how to build a team, motivate people etc). His idea of management was micromanaging and treating his colleagues as a ‘pair of hands’ using ironically a ticketing system that you’ve mentioned. It didn’t work because when he opened tickets half of the tickets were very poorly documented leading to disputes regarding if the work is done or not. Also, his reporting absolutely sucked, he did not use anything to measure productivity and just blamed the developers at the first sign of trouble.

            When you practice project management,you quickly learn that it is less about technical ability, but more about understanding people, learning how to get the best out of them, and putting management processes in the operational side of the business (reporting, structuring your resources properly) in place to get the team to collaboratively work together to help the PM deliver a high quality product.

            As a former developer/project manager that has worked in many organisations – from start up’s to agencies, aside from the above, I have seen how poor project/product management has caused excessive delays, and ends up costing the company more in the long run since it affects their ability to execute in a timely manner. Very often this in turn causes cashflow problems, or allows the competition to catch up. Having a trained project manager on board to keep things streamlined reduces the risk of this happening.

          5. Adrian83

            @SS

            The idea is than in a project the role of the project manager is optional. It is possible to deliver without having a project manager and many IT projects (mostly smaller ones) are delivered in this way. It is not the team who helps the project manager deliver but it is the other way around. Project managers are brought mainly to improve the performance of the activities that involve change. The benefits that project management brings however depend on the nature of the change activity and in some activities elaborate project management methodology and professional project managers simply make no sense as they will not bring real benefits to the business.

            I will give a clear example. I had recently worked for about 2 years supporting the GIS applications used by a large utilities company. By supporting I mean I was fully responsible for all the aspects of the applications including developing new features. I was working at the customer site collocated with the team that was using the applications so for any issue they had with the applications they came straight to my desk and talk about them.

            If they wanted new features they simply came to me and told me what they had wanted, I was analyzing the requirements figure out what needs to be done and then started to do the actual work. I was working in a development environment where the users had access so they were testing during development and they were able to give me further instructions about the new features they wanted. The requirements were recorded as request for change records into a system and it was the senior user who decided which requirements had higher priority.

            While we were not using any agile methodology in my opinion this was real agile as the users were directly driving the development and there was absolutely no doubt that what I was developing was actually what they wanted. In addition, there was no pressure to finish in a set time or budget (the company was paying a fix sum for support) and the scope creep was no issue as they were able to change their mind about a certain enhancement while I was working on it with absolutely no impact on the budget. I am not sure if the contract had a minimum number of enhancements included but the users were very happy with the progress and with the ability to basically do whatever they wanted to the applications.

            Once the work was done for a requirement it entered a Change Advisory Board process and once approved I was allowed to release it into the production environment. The CAB was managing changes for the whole IT department not only for my applications.

            The real limitation of this setup was the fact that the amount of requirements I was able to complete was limited by the time I had to work on them as the defects and other issues had higher priority. If they wanted the requirements to be done faster their manager had to sponsor a project which meant, he had to allocated extra money from his budget for this. The requirements had to be estimated and according to the estimation the required budget was defined. The functional manager decided how much money he wanted to spend and as such some requirements had to remain out of scope and they were done as part of the Business as Usual process.

            When a project was started usually another consultant was assigned so that the requirements can be completed faster. Also project managers were assigned for each project but they were dealing with reporting and other administrative tasks and they were not involved at all in the execution of the project as the consultants were doing all the work including directly interacting with the customers. Each project manager was “managing” several projects simultaneously as there was not much work for them to do on each project.

          6. SS

            We are going around in circles, but to cut a long story short if you are the only person working on a client project it is NOT management. When I am managing, I am managing a cross functional team consisting of UI/UX, developers, QA testers to work together throughout the whole software development lifecycle to help me deliver a project.

            Also what you describe when it comes to agile is agile not properly executed, which is all about releasing the product in increments. If you are finding that there is a lot of change requests with the client it basically means that you have not done a great job with speccing what they wanted originally to begin with.

            Finally your project management style does not even scale, yes if you are one guy working on a client project it’s easy. But what if you have a team of developers working on it? 10 + are you honestly going to tell me that you will be able to focus on all of the technical work and manage their productivity at the same time? – basically be an account manager, developer, scrum master, product manager – you will be so overwhelmed that it will be hard to focus on coding.

          7. Adrian83

            @SS

            Please don’t get me wrong I am not trying to say that project management or other non-technical activities auxiliary to software development are useless. All I am saying is that in many circumstances some of these auxiliary activities are an unnecessary overhead that brings no benefit but slows down development.

            When you implement a new solution and have a lot of stakeholders and a cross functional team then yes you definitely need someone to see the big picture and to manage the communication between all the stakeholders. I am not contesting the benefits of project management in general I am just saying that there are many commercial software development activities that simply don’t need project managers.

            When I worked on supporting those GIS applications at some point the users had needed a new type of fiber terminal in their network to model a new situation that was not present from the beginning. For this requirement the data model had to be changed to accommodate a new table and new fields and also the code had to be changed to support new functionality for the new objects.

            If this had been done through a project it would have taken much more time to complete because it would have involved more people such as a project manager, business analyst, quality assurance engineer and maybe a solution architect. The project manager had to organize meetings for all these people to meet and discuss about the new features and decide what needs to be done but I already knew what needs to be done and I needed no further help from someone else. I had just started working in the development environment and when done the users had tested and approved the change. I then got the approval from the Change Advisory Board and finally I put the changes into the production environment. Very fast and efficient with no unnecessary overhead.

            I repeat I am not saying that project management is useless and I do understand that in more complex projects there is simply impossible for technical leads or other technical people to manage the operational aspects of the project. Nonetheless even when a project manager is actually needed and he brings real benefits to the project the team does not help him deliver but instead he helps the team to maximize its potential. At least this is how I see things.

            Finally, users requesting new features after the project had finished does not mean that the project had failed to capture all the requirements. Usually users want more features than the budget allocated by the functional manager allows and the missing features are normally implemented in future projects or as part of the support operations. But more importantly, as I have already said, the business processes change over time and new features need to be added to the application in order to accommodate these changes.

          8. SS

            @Adrian83

            I am glad that we are on the same page.

            To summarise

            1) If it is a project that requires one person, and it is a short one off project, then it is probably not complex enough to warrant a PM. Many software companies and agencies, do not hire PMs for these type of roles.

            2) If the project involves getting a cross functional team together to help deliver a couples project/product than a PM is vital in order to keep the communication lines open, and delegate work correctly..

            To give you an example of my day to day duties, I am currently product managing a product of a team of 4 people. Before I came on board, the product was poorly written, working with the team my task was to help them launch a newer version of the product. Previously the challenges the company had was that they were managing it how they always had done so before, they would:

            – give the dev team a shopping list worth of work which is unrealistic in the time frame expected
            – not doing proper QA based on properly written specs leading to a lot of bugs or worse still functionality that the client did not want built.
            – asking for a 1000 change requests when the developers are already half way though working through a task. Causing them to lose focus with completing tasks from distracted, leading to poorer quality work being produced.
            – Delegating work to staff that were too junior for it

            Once I came on board, I:

            – Put processes in place to do efficient QA by writing descriptive user acceptance criterias.
            – Changed the way the company worked so that they released increments of the product every fortnight
            – If the client requested changes it was prioritised based on the upcoming sprints.
            – Managing stakeholder expectations by showing them reporting of the team’s velocity relative to the amount of work left. Changing the way they think about the process of software development.
            – Doing all the admin side – requirement gathering etc, so that the team doesn’t.

            The end result:

            – high quality product
            – happier developers
            – happy stakeholder
            – more focused team. Since they can get on with what they are good at.

            Where am I going with this, the people complaining on this blog post have no idea about what goes into project management, arguably it is much more complex then the tech side since it is all about planning and execution. Real people can also be tricky to manage at times since they have to always be motivated and have a sense of purpose in order to get the best out of them.

      2. Edgy

        Understood Lee. Everyone does the best he can in a team. But that best could be put to waste and the team could become lame when nobody is coordinating are reporting progress. And remember, the bosses only want the bottomline which the reports that the PMs give can serve.

        Reply
    2. S

      I was a developer, now I am a PM and I can tell you that PMs are extremely important when it comes to delivering a project on time in budget. I have worked with tech leads who are extremely technical but had no clue how to motivate the team to get work delivered. My ex line manager was like this.

      Sure – they are not expected to code, and often do not. But outside of that, they are the first point of call for clients; they also have to make sure the work is being delegated properly; constantly motivate the team; deal with any impediments. To top it off , PMs are often judged by how efficiently they are able to deliver the projects on time and within budget.

      It sounds like you have worked under bad PMs.

      Reply
  4. EezieE

    I’ve worked with a bunch of bad ones and few good ones. The good ones prioritize requests, make educated judgement calls on which tasks a developer should devote her resources on, can answer questions about technical requirements.

    That said, most of the PMs I’ve worked with are abysmally incompetent serving as nothing more than glorified secretaries. For the recent project the one checking QA status, prioritizing bugs, confirming business requirements, is ME, THE DEVELOPER. 1. The PM couldn’t answer ANY of QA’s questions whether this or that bug is launch critical or not. 2. The PM failed to assign the most important tasks to me, 3. nor did they rank various QA feedback in ANY order of importance. I don’t know what their role is, they’re out of the office half the time. All I see them do is scheduling meetings on the calendar and taking attendance at stand-ups and ask “Is it done yet?” If it’s not, they wouldn’t know what to do. If it is, then they’ve “done their job”, which is nothing basically.

    Reply
    1. underrated

      Everything you said is correct. Have you forgotten to mention that these scum of the scums however take part in calibrating their employees and give them a performance rating, and make their life hell?

      Reply
      1. Adrian83

        Doing the performance review of an employee (who is not a line manager) requires the reviewer to be from the same line of work as the employee. That’s because the technical aspects of the employee’s work have to be taken into account.

        If the project manager is a good technical expert being able to do the work of the team members then he/she may be allowed to evaluate their performance or at least send performance feedback to the team member’s line managers.

        Project managers without technical background or who are not very competent technical experts are typically not allowed to review the performance of the project team members as they don’t have the competence to evaluate the technical skills.

        Companies that allow non-technical project managers to evaluate the technical abilities of the employees working on projects may end up loosing their best human resource as the work of this resources may not be well rewarded. In addition the workers may feel themselves humiliated when someone that is not able to do their work evaluates how well the work was performed.

        Reply
        1. SS

          First and foremost, you are right a non technical PM should not evaluate a technical person’s work. Although as a PM, I do think that it is important that the PM should have some technical awareness, but at the same time I am aware that there are many companies who do not hire technical PMs.

          Secondly, the problem with this whole debate is that you have a lot of PMs that do not do things properly in terms of measuring productivity. If for example you do follow the right methodology it is easy to measure progress of the team.

          For example Agile, when work is delegated it is done during sprint planning sessions where with the Product Manager and the team agree on what backlog items to complete in that week. The scrum master then takes over (some do both roles) and productivity during sprints is then measured based on velocity using burndown charts etc. Hence, if the dev team agreed to complete x amount of work but never manage to meet their sprint goals and always behind on their sprints, there is obviously something wrong with either the way the sprints are organised (too much work), or the developers are just not good enough. If done properly, you can work this out as a non technical PM, you do not need to be technical.

          Now if you have a tech lead, and their strength is coding, do you not think it’s better for them to be involved with the rest of the dev team coding during the sprint as opposed to administrating it? The whole point of the sprint is that the dev team can do what they do best and NOT get interrupted by stakeholders etc…somebody has to do this job.

          A lot of the people moaning here, are clearly disgruntled developers who do not understand why project management is important. They have probably also worked with terrible PMs, who just order people around.

          From doing this, I have seen that so much more work gets done when you have a clear separation from operations and the hands on technical side of the business, since the developers become much more focused on developing new features etc.

          Reply
          1. underrated

            We all agree that non technical PMs should not be allowed to evaluate the performance of technical employees. But Google, which is a much hyped dream company has exactly this abominable setup. Peers also provide reviews but peers’ reviews only get considered for promotions, not for calibrations which is a separate process. For calibration, the manager gives a score even if he is a non-technical idiot.

    2. SS

      +1

      As a PM, I have dealt with other PM’s that are how you described. Since I come from a pretty technical background and do QA, and learn about what is going on (sometimes suggesting to the dev team how the problem could be solved) it absolutely pains me when I meet a PM who has no clue at all. These are the type of PMs that give the rest of us a bad name. I am no longer hands on, but I do so much reporting that I wouldn’t have the time to be. There is a lot to PM if you run your projects in an agile way.

      Reply
  5. R

    A complicated task or business objective needs project managers to implement manage and deliver them, someone needs to be accountable for a projects success or failure at the end of the day, projects have critical paths and tasks that requirement such as planning, seeking approvals, time and budget management, risk management contract management and many other crucial business impacting tasks that need to be considered, Without project managers there will be no plan, no time management, budget blowouts, risks which could put the company’s reputation In jepotdy, etc etc the biggest concern for a project manager speaking from experience is “people management” if you cannot built relationships with your project management team all of the above will be a nightmare, I have seen other project managers struggle in this area and it only results in their reputation being tarnished by the team,

    Reply
    1. Edgy

      Absolutely agree with you R. Every PM must be sharply honed with that art of “people management.” In the company where I works as A Project Engineer, I always deal with people that belong to different discipline: Product Engineer, Process Engineer, Technicians, Production Sups, QAs, Planers, Supply Chain Analysts (SCAs). Each one has their own mandate for the day. And if he is not reporting to you and the Task is not his priority for that day, he won’t update or take the Task loosely. You’ve got to be patient and got tons of provision of it for explaining later to the Boss why the Task is late…and here is the catch: the explanation should not give impression that you are blaming the Task Owner. He takes it as you burning the bridge. This is where I learned to fatten my Emotional Quotient. Even if I hate a member, I have to find a way to like him to the point of treating for a dine or drink or be the first one to greet happy b-day and give gift–just to win his emotion and not to snub my update next time.
      It works most of the time…but there are really some people who are borne with obstinate horns!

      Reply
  6. R

    Ps – I have a technical engineering background with a project management degree and the project managers I see struggle are the ones who have no technical capability, it’s hard to build relationships with project engineers when you can’t speak their “engineer Lingo” same goes for “executive msnagement” you need to speak there lingo to that’s why I went and did an MBA after – sad but true!!

    Reply
  7. R

    Btw – mind the spelling (it’s 4.30 am)

    Reply
  8. Ben

    Obviously, if you think PM’s are not needed your projects are too small. I’m a technical PM but more a Delivery Manager/Solutions Engineer/Developer/BA/etc. I’ve worked in sales, fulfillment, support and development of an online marketing company. We’ve built new platforms, platform integrations, migrations..you name it, we’ve done it.

    As a tech PM I handle the managing of development, the architecture, business and tech requirements, documentation, (what API/Daemon pushes what data) and making it sure that what is being developed is functional for all channels. I work my butt off to produce and exceed expectations. Without a PM to manage the project as a whole, who drives marketing/documentation/communications and/or every other aspect beyond the technical side? Someone is going to use what is being developed and it is likely more than just CX but a global CX. Every front end also has a back end.

    I will tell you this, there are more terrible PM’s than good PM’s by a landslide. However, if you get a good one, you will know it. I don’t doubt that if you handle projects to create a simple db with a UI that’s used internally, that you do not need a PM. However, if you are developing a new control panel with integration of several other platforms, a front end user experience, a back end user experience and training several hundred sales/support/fulfillment reps on the new integrated platform, you’d better have a dang good PM running the show or that project will be disastrous.

    Reply
  9. DD

    All engineers are mad because the PM is above them. LOL sad but true, they hate that they cannot be leaders nor make good judgement when things get tough. PM’s are strong and good leaders so all the cry baby engineers grow up and keep working!

    Reply
    1. Kp

      What on earth are you talking about you’re just a glorified secretary. What judgment ? You still have to talk to upper management and explained the risks so that you can wash your hands if it fails, remember re-mediation tasks tasks ? Can a project manager survive without an engineer or architect ? I dont think so.. But can an architect or engineer survive without a project manager? Guess how startups are made.

      Reply
    2. Adrian83

      Engineers can’t be leaders? You’ve got to be kidding. Managers in engineering companies/engineering departments are promoted from among engineers and not from among project managers. In fact project managers in the overwhelming majority of cases are not even real managers as nobody reports to them not even the project team members.

      Also the overwhelming majority of decisions that engineers do care about are technical in nature. If the project manager is not also a very experienced engineer then he will not lead the engineers as they expect technical direction from their leader something that he/she will not be able to provide.

      Project managers have their very well established place in technical projects however they don’t get involved in engineering or in leading the engineers.

      Reply
      1. SS

        Engineers who are Managers are called ‘Tech leads’.

        Not all tech leads are good at project managers, which requires a different set of skills; good communication skills with stakeholders and other parties; reporting (gaant, burndown charts, maintaining the product road map etc) and budgeting.

        A good tech lead should be focusing purely on the technical aspect of things, as opposed to being involved in operations which is what a PM does.

        Reply
        1. Adrian83

          Engineers who are managers are called: engineering managers, directors of engineering, vice-presidents of engineering and chief technology officers. Well they don’t do much engineering but in order to get on these jobs in almost all cases you must have an engineering background. This positions are known also as functional managers (with the exception of the CTO who is an executive manager).

          Technical leads are not managers they are technical experts such as engineers who are responsible for leading a group of people from their own line of work during a work activity such as a project. The role of the technical lead is usually not permanent an engineer may function as a technical lead on a project and as an “ordinary” engineer on another.

          Project managers are not managers either, but instead they are professionals in the field of project management responsible for managing the operational aspects of projects. It is very true that not all technical leads are good project managers but in most companies technical leads are not expected to do project management so this is not a problem. :)

          In many if not in most companies engineers and project managers are at the same level (the bottom of the chart) and they have different career path options. Engineers can become functional team leads, engineering managers, directors of engineering and at the highest level possible chief technology officers.

          Project managers can become program managers and then they can end up leading the project/program/portfolio structures from the organization in which they work.

          Reply
          1. SS

            There you go, that proves my point that people on here complaining about PM’s do not know what they exactly do, and therefore do not see the value of having them!

            They are not glorified secretaries.

            In a nutshell, they help run the operational side of the business whilst the tech lead/manager needs to keep up to date with tech trends and all things technical and work with the PM. The PM does not have to be technical. Though it helps.

            Skills such as:

            – Resource management
            – Stakeholder management, which for the record is very hard if dealing with impatient stakeholders.
            – Reporting progress using reports
            – Budgeting
            – Awareness of different project management methodologies and WHEN to use them
            – Planning, forecasting
            – Delivering projects on time and within budget
            – Dealing with conflicts/impediments as they occur

            These are all non technical skills a PM must have to ensure that everything on operations goes smoothly. A good PM will take the pain from the development team on the operational side so that they can focus on doing what they do best, writing code and implementing functional specs.

            For the guy who responded to me telling me that start ups need developers, but don’t need a PM. The last start up that I had worked in that took this approach ended up having endless delays from poor requirement gathering and a lack of overall planning on how work should be distributed with the Dev team. The person managing the start up was a tech lead assuming the role as PM.

  10. underrated

    SS, them PMs may bring a small value as you say, as does the janitor. Why don’t these PMs be under engineers and get a fraction of their salary, coz that’s what is the right thing to happen. Which psycho invented them to be above engineers and get paid more than them?

    Reply
    1. SS

      Underrated, you are missing the point.

      They are two completely different jobs, one job (engineers) is about building things, the other is about ensuring things that are built by engineers is done in a timely manner.

      I was a former developer before being a PM, when I was a developer in some ways my life was easier. Daily routine would consist of getting a list of functional specifications, and just implementing them. I had less responsibility.

      As a PM, I have a huge amount of responsibility, I have to make sure that everyone in the cross functional teams works together in a cohesive manner to help me deliver a project on time. That is why PM gets paid a lot, the job is stressful from carrying more responsibility and with that comes more accountability when things go wrong. I.e. Delays, project going over budget etc

      Reply
    2. Adrian83

      It depends on the company but usually large companies use something that is being know as the weak matrix organization. This means that the project managers are not above engineers but instead they are at the same level on the company chart as employees sitting at the bottom of the hierarchy with no one reporting to them.

      Project managers usually sit above engineers in the cases where becoming a project manager is part of the engineer’s career path. This means that the project manager in this cases is an engineer promoted to a higher position. This is known as the strong matrix organization.

      If the project manager is not an engineer then he usually does not sit above engineers and the engineers in this case report to some kind of engineering manager which is an engineer promoted to management.

      Regarding the pay it depends on the company. Usually companies value more the employees that are in direct contact with the customer and that’s why project managers that manage projects delivered to customers usually make more money than the average engineer.

      On the other hand top technical resources in many companies are paid much more than the average project manager as they are more important. Loosing a good project managers is usually less important then loosing your top technical resource. Loosing an average engineer is also less important that loosing a good project manager.

      Lastly projects are not born equal as some of them require far more project management expertise than others. This can lead to projects where there is not much work for the project manager to do. In this kind of projects the PM is essentially an over paid administrative assistant and if he/she is paid more than the engineers then the engineer’s frustration is fully justified.

      Reply
  11. SS

    Once again this argument is flawed in the sense that it is comparing apples and oranges.

    In many organisations PMs and Engineers work together – Adrian, you are right, PMs have to deal with the customer, may it be stakeholders or externally which makes it a very stressful job. Anyone who has done account management would understand this. Many developers bitching on here thinking that being client facing is not as ‘hard’ as coding, but I would love for them to experience a situation where there are massive delays with the customer threatening to stop doing business with the company over it and see how they calm the customer down especially when the customer is not technically minded (often the case)

    To add to the complexity, if it turns out that the company ends up losing a client (affecting cash flow), the Dev team does not get blamed. The PMs neck is on the chopping board. The pressure from knowing that alone adds to the stress. Adrian when you think about it this way, it is unfair that you compare PMs to administrators, many admins have far less responsibility than a PM where their actions do not affect other departments in the same way – sales, HR, technical since they are not delivering projects using resources from these departments but passing information around. That is an extremely important distinction between the two roles.

    Both engineers and PMs are paid well for different reasons. Reasons such as above is one example why a PM is paid well. Other stresses in the job include leadership skills, motivating, keeping morale in the team high so that projects are delivered smoothly on time and within budget. Easier said than done, when working with difficult colleagues.

    Now to give an example of the above, recently I was in a situation when trying to deliver a project but the developer was either not doing the work, or very slowly. Now I can’t just complain about this the CEO or stakeholders, to save my neck, I have to first have substantial proof that he indeed is not doing the work from adequate reporting, once that is done I then had to find a replacement.

    Again, sounds easy? How about putting yourself in a situation when your team are not hitting deadlines for the reason above. Resolving resource bottlenecks and making decisive decisions is part of the job and requires leadership and strong management skills.

    These are just two types of scienario a PM has to deal with, there are many more.

    The problem with technical people is that they only care about technical aspects of an organisation and are out of touch with the companies strategy in the next quarter which is defined in operations.

    Reply
  12. Adrian83

    @SS

    I didn’t say that project managers in general are administrative assistants. I only said that this depends on the project. Whether you accept this or not there are a lot of projects in IT (usually less complex ones) where there is simply no need for professional project managers. There are projects where there is a single technical consultant/developer who talks directly to the customer figures out what he needs to do and does it by himself/herself.

    In addition some companies add enhancements to their software as part of a support contract which means that for a fixed periodic fee the users can log requests for both bug fixing as well as for enhancing the application. In this scenario we don’t even have a project.

    As for evaluating the performance of employees, project managers, unless they are also very competent technical experts themselves shouldn’t and usually are not allowed to do this.

    The fact that a developer misses dead lines does not mean that he is a poor professional. The dead line might have been imposed on him by people that have no idea of the work that needs to be done and he may not be willing to take shortcuts and deliver a poor product or a product with a lot of technical debt in it.

    The performance of a technical expert can only be truly evaluated by another technical expert. Personally I have never seen cases where the project manager can kick someone out of a project for performance reasons. The best he can do is raise the issue about the performance problem and escalate it to a decision maker such as the project sponsor or the line manager the team member reports to. If the decision maker concludes that there is no performance issue then the PM has to live with this decision. Sometimes even if there is a performance issue the sponsor or the line manager can’t find a better expert for the job so tough luck for the PM.

    In the companies for which I have worked the PMs were not solely responsible for the outcome of the projects but instead the line managers were also responsible for their part of the work. Project managers were not even recruiting team members but instead they went to line managers who were responsible for allocating resources to the projects and ensuring that they perform at their best. If a team member was not performing well on a project then his/her line manager would have been held accountable for that and not the project manager.

    Reply
    1. SS

      Adrian, don’t get me wrong, coming from a technical background does help immensely. Very often when I am managing my in house team, and they run into technical problems I help them out where I can when they are stuck. I do think that all PMs should have some technical awareness in order to better understand the project so that they know what they are trying to deliver. However, they don’t need to be an expert, they just need to be competent.

      The bulk of my work however is largely focused around my soft skills rather than my technical skills. I spend A LOT of my time planning upcoming sprints on a weekly bases and ensuring the work is delivered – I’m currently leading a team building a start up product using Scrum. To do this properly, I have to work with the product owner and devise as well as maintain a product roadmap which is in line with the needs of the market based on the user stories in the backlog. This is not technical at all, but more in line of PM/business analysis.

      I disagree with your opinion that productivity can’t be measured!

      Productivity can be measured using cumulative flow diagrams , burn down charts, and allocating reasonable story points to user stories in the sprints. The story points FYI are not set by the PM but done collectively together during sprint planning sessions so that the complexity of the task is discussed and agreed with the technical team before a story point is set.

      If done properly you can work out the average velocity of the technical team using burn down charts over period of several sprints. This is then used as a guide for future forecasting on how long it will take to deliver future work and during the sprint help the agile project manager keep the team on track by reviewing the teams velocity at the end of each day on a burn down chart once the sprint has undergone.

      If the team works a certain velocity, where the velocity suddenly drops then there is something wrong. I.e if they stop meeting their sprint goals, or start to continues let fall behind on the burn downs.

      A good PM needs to also know how to switch methodologies, for some projects I don’t do scrum I do kanban. When I do kanban, I track someone’s work rate based on their cycle time.

      So you see, what I have described above is low level project management.

      Knowledge of when to apply different PM frameworks to get a project delivered in the most efficient at possible; using various reporting tools to measure productivity and KNOW HOW to do it properly adds another dimension to it.

      Reply
  13. Adrian83

    @SS

    Software development unlike construction, manufacturing, digging trenches, etc. is a creative activity where you can never accurately estimate the effort needed to complete a task. Because of this it is virtually impossible to accurately measure productivity in this field especially by using statistic data that tells you how fast do developers complete their tasks.

    If you are digging trenches and know in a working day, the length of the trench the workers can dig then it is very easy to estimate how much time the whole trench will take to complete. If you want it done faster, you can add more workers in shifts and you can accurately estimate the new end date.

    The trench estimation however does not work in software development. If you look through statistics and find out in average the number of tasks/user stories a team or a developer completes in a certain period of time it is foolish to use this information in order to calculate the number of tasks the developer or the team will complete in a future period of time.

    Even if the developers work as hard as they did before and have no impediments it is perfectly normal for their “rate” to variate, sometimes even dramatically. I can think of a lot of reasons for that: the complexity of the tasks is much higher, the complexity does not change but the developers have to use different APIs or algorithms that they haven’t used before, the developers have to pay the technical debt that they had either produced in previous projects/ sprints/ project phases or the technical debt was already there produces by someone else. Not to mention the lack of inspiration that developers can have some times. If you are working on a more complex task the idea on how to do it can come to you straight away or in a couple days or maybe never.

    While my work now involves a lot of coding I am not a pure developer as I also interact directly with users on gathering requirements and defining solutions for their problems. At my beginning of my career I worked as a pure developer and one of my first assignments involved outsourced bug fixing and enhancements. My company was paid by the number of bugs fixed. You can imagine by yourself what happened, we worked as hard to fix as much bugs as possible without carrying too much on the quality or on preventing technical debt. Many of our bugs returned to us as they failed technical review or testing and even those that passed were a sloppy job as all we cared about was speed.

    If the developers line managers look at this kind of statistics for performance review and pay raises purposes, then things can get really messy as less competent developers may end up with better pay because they worked on easier tasks that they were able to complete faster.

    Reply
    1. SS

      Adrian, the whole point of agile is to not 100 percent work out how long a task will take, but to plan your sprints based on the complexity of tasks relative to others.

      If this is done well, you’ll eventually see a pattern over several sprints with regards to how many story points the Dev team can complete on average. You can find this information by comparing past velocity on burn down charts.

      My Dev team for example completes 9.5 points on average. Hence, if I plan the sprints with less points, I often have found that they end up finishing well ahead of schedule. Similarly, if sprints are planned with more points then they risk not finishing all of the work in the week. It’s the PM job to work out the happy medium.

      Finally, and the point that you are missing. The agile PM does not decide the story points of tasks without first discussing this with the Dev team. The whole point of the discussion is so that the team as accurately as possible measure how ‘complex’ a task is (note: this not measured in time) relative to another.

      A skilled PM, knows how to consistently do this. They can also use this as a guide to measure productivity, if for weeks on end my team are completing 9.5 points worth of work, than all of a sudden can only complete 3 points worth, then it’s reasonable to believe that there is something wrong – either with the developer not working hard enough or if the tasks are not properly estimated.

      In addition, you can use a cumulative flow diagram to see the overall progress of one developer.

      I can tell from reading your post, that you are not a PM at all but a pure technical person that has probably worked in non agile environments.

      Reply
  14. SS

    @Adrian, to add.

    The fundamental problem with your whole approach, which is basically leaving the developers to self manage is that you leave yourself vulnerable to a developer setting unrealistic timeframes, in turn producing very little.

    In addition, when dealing with stakeholders you need to be able to give them timeframes as accurately as possible. You cannot go in and say:

    ‘Hmmm I don’t know, the problem with software development is because it is hard to estimate mmmm…how long is a piece of string?’

    Agile is not meant to be 100 percent accurate, but it is a lot better than the way you are doing things, which is pure guesswork and does not scale when trying to work out the work rate of whole Dev teams.

    Commercial development does not work this way. Like it or not, developers need to deliver work based on timeframes.

    Reply
    1. Adrian83

      @SS

      In all activities, whether or not we talking about software development, the subject matter experts that have experience in doing the work are the best people to do the estimation for the time needed to complete the work.

      I don’t want to offend you in any way ( I don’t even know you) but saying that the software developers are not the best people to estimate the time needed to complete software development tasks is simply absurd. It is statements like this that make some project managers get no respect from technical people.

      Is like you are saying to a professional in a certain field that he is too stupid to estimate his own work and you, even if you are not as good as the expert or are a total non-expert, can better estimate then he can. And the bottom line would be to hold accountable the expert on the estimation that you as a non-expert or as a less competent expert did.

      On all the projects on which I have worked the effort needed to complete certain tasks was either estimated by me or by a better technical expert that was on the team (technical lead, solution architect).

      If the estimations are too long then the project manager will try to find solutions by engaging other people or trying to get new members on board to help. It is the technical people and not the project managers the ones that will find the solution, the project manager will just guide and engage the experts and other stakeholders on finding the solution. If everything fails then is it the obligation of the project manager to raise the issue to the sponsor warning that the project has a high probability of failure because of unrealistic expectations.

      On the projects on which I have worked the project manager (when one actually existed) was not responsible for taking decisions regarding the project but instead he/she had to find out what decisions have to be taken and then ask the right stakeholder to take them. When it was time for estimations the PM asked the technical experts to produce them.

      In my opinion, unless we are talking about less complex projects, the role of the project manager is very important but his value doesn’t come from getting the status, writing reports or from gathering statistical data but instead from managing the communication between stakeholders and translating the status of the project to the customer in such a way that the customer will be happy and be convinced that he will receive a good product or service. In my opinion only for these activities the PMs deserves a high pay.

      The best project manager is the one that makes all the stakeholder happy. :) A project manager that doesn’t do much stakeholder management does not bring much value and he/she is basically a glorified secretary.

      Reply
  15. SS

    @Adrian

    I never said that software developers should not estimate their work, more to the point during ‘Scrum planning sessions’, I encourage this and it leads to a discussion. I just think that you should not blindly accept developer estimates when you are managing them.

    As a Agile PM/Scrum master, I often challenge the development team (I come from a technical background so I can do this) in case they give an estimate that is too conservative. I have seen this happen many times, where the developer judges the complexity of a task to be 3 points worth, but after the team questions why and discuss the problem throughly, the effort can be less.

    I totally agree that stakeholder management is important, it is something I do daily in my role when I report to the product owner. Often this is very challenging if the stakeholder is non technical and when things are not going well.

    Reply
  16. Adrian83

    At the beginning of my career I worked as a developer on a Scrum team responsible for the development of a software product. This was not part of a project, we were not directly delivering anything to customers and as such there was no project manager on the team ( there was no need for one).

    This was my only interaction with the Agile world so I am not an expert on this. However I have learned that self managed teams is one of the core values of Scrum Agile. This means that the Scrum Master/PM is just a facilitator that is not allowed to take decisions but instead he/she must help the team take decisions. This means that the Scrum Master/PM can’t theoretical change the estimations made by the team.

    The reality however is that even in non-Agile projects the PM in most cases still acts as a facilitator who is not authorized to estimate the effort needed to complete tasks. Many if not most of the software PMs (either Agile or not) don’t come from a developer background and as such they lack any competence on this matter.

    Of course this doesn’t mean that the PM has to blindly accept any estimation made by the developers but he can’t reduce the estimations either. He must ask the team to reconsider the estimations (if they are too long) and engage the team members to find solutions on completing the work in less time. This however will usually result in technical debt or in a large number of bugs as the team will not have the time to write quality code. If the team (technical leads especially) remains firm on its estimations then the PM has no other option then raising the issue to a higher level.

    Now regarding managing developers it is important to understand the difference between managing the tasks of a group of people that are involved in an activity and managing people.

    Managing people involves things such as:
    – hiring an firing employees,
    – managing the work assignments of employees (for example on which projects they should work),
    – providing technical leadership in guidance to employees,
    – taking high level technical decisions,
    – evaluating the professional performance of employees and taking actions to improve it,
    – managing the employees rewards system (pay raises, bonuses, other benefits)
    – sanctioning the employees for wrong doings.

    Managing people, as a general rule, is not the responsibility of the project manager but that of the functional manager and technical leads. In smaller companies however the same persons my play both roles.

    Reply
    1. SS

      Indeed, that is how Scrum works.

      I do not decide the estimates for the team, they do but I do during sprint planning session question why the estimate is that and if they should reconsider. When I ask them to reconsider it is based on experience – if the developer says ‘the task is 3 points worth’ but then in previous sprints they had done something similar and saw that the complexity is less than what they are estimating now. I know that they are misleading me in order to be less productive.

      There is a lot of reporting tools in agile where even if you are not technical can get an idea of the teams overall performance. The whole point of the scrum master is relaying progress back to the stakeholder and optimising the sprints so the time the developers have is used efficiently.

      Reply
  17. SS

    @adrian, Google ‘poker planning sessions’ to get an understanding on how I do my estimations.

    Actually, the following is a good article that covers this activity:

    https://www.mountaingoatsoftware.com/agile/planning-poker

    There is a lot of discussion with the scrum team in the planning, which is extremely important.

    Reply
    1. M

      Some PM definitely got plenty of time to reply every comment and fight back to prove his/her little use. Keep up the spirit! lol

      Reply
      1. SS

        Maybe because I am getting email notifications on my smartphone…moron.

        Reply
  18. Kp

    Holy cow this thread has been running for an epic long time, but yes think of a project manager as a glorified secretary. They are necessary to report to the higher ups on the status of the project. however technical leads and architects are way more important than project managers don’t think that the project managers are all that believe me a project manager is much easier to replace as every non-technical IT personnel that I’ve bumped into wants to be one . You look technical.. But are you?

    Reply
    1. SS

      @kp you are comparing apples with oranges. Technical people do technical work, a PMs responsibility (well mine) is to ensure the operational side of the business is running smoothly. This might sound easy, but it isn’t….finding the resources and managing them so that they help you deliver work smoothly can at times be extremely tricky. For example, last week I was in a situation where a sub contractor I was working with was threatening to stop working on a project I was delivering because he felt that he wasn’t paid enough. I spent the whole morning sorting this out and it was extremely stressful since I need him to complete his work so that we can deliver it to the client without going out of budget.

      Meanwhile the technical team, are sheltered from this. Whilst I am sorting that out , they are coding etc.

      So no comparing PMs to glorified secretaries is extremely disrespectful. We have huge responsibility and accountability, we have to make sure projects are delivered in time and on budget. If we do not then the company can fold, since customers will not be willing to pay, or sub contractors such as the above cause the project budget to go out of whack affecting the companies revenue stream.

      Reply
      1. Adrian83

        Yes I agree that comparing PMs with glorified secretaries is disrespectful, even in small projects where PMs are actually performing a work similar to secretaries. However I find it equally disrespectful for PMs to claim that they deliver the project and the team members only help.

        Saying that the team members help the PM deliver implies the fact that the team members play a minor role in the project. In reality however if you drop the PM you can still deliver (and many small companies do deliver projects without PMs) but if you drop the team members then you have no project.

        Since the project manager is an optional resource on a project team it is him/her the one that helps the team deliver and not the other way around. Any member of the project team can perform the work of the PM but in complex projects it is not a good idea to have a team members doing this work and it is much better to employ a professional project manager.

        I also find it disrespectful when PMs claim that they ensure that the project is being delivered on time and budget when in reality equally important if not more important is the effort made by the team.

        Reply
        1. SS

          At the end of the day, yes, a PM role is optional, but then that goes with many roles that are not technical. I have worked in start ups where they carry a ‘do it yourself’ approach for sales, and marketing. Only because it ‘looks easy’ does not mean it is.

          Before I took on my current role as a PM, I worked in one company that is a start up, where I was a web developer, the organisation took your approach and left all managerial responsibility to the tech lead. Guess what happened? In that instance, the project quickly spiralled out of control in terms of budget and delays. Despite the tech lead being technically able, he was very bad at putting *non technical* processes in place to make things more efficient by reducing costs and ensuring things were delivered smoothly. Similarly, when any impediments arose with his colleagues, instead of diplomatically resolving the situation, he created a culture of blame.

          Project managers are hired for a reason, they are not there to provide technical support, they are to ensure that things are extremely organised where impediments are dealt with quickly in the smoothest way possible. A lot of this is on the operational side of the business and requires strong organisational plus interpersonal skills – they also need to have commercial awareness of how the business operates and what it is trying to objectively achieve. A secretary doesn’t, and is not part of the bigger picture which is why it is an unfair comparison.

          It is good for the PM to have technical awareness, and it helps me a lot, but at the same time, I do not need to know it at a very low level, just enough so that the developer doesn’t bullshit me and even if I didn’t have any technical knowledge with the right reporting I could still work out if the developer is bullshitting me i.e. if the developer constantly commits to delivering work, but fails time and time again.

          Frankly, it is the arrogance that is displayed in this thread that is really pissing me off. Developers on here are clearly frowning on PMs, yet don’t realise how important their role is ensuring that everyone is motivated and in turn productive which in turn leads to a project being delivered in a timely manner tying into the commercial objectives of the business. That is the reason why many digital agencies hire Digital project managers, along with larger companies.

          Reply
          1. Adrian83

            @SS

            “It is good for the PM to have technical awareness, and it helps me a lot, but at the same time, I do not need to know it at a very low level, just enough so that the developer doesn’t bullshit me and even if I didn’t have any technical knowledge with the right reporting I could still work out if the developer is bullshitting me i.e. if the developer constantly commits to delivering work, but fails time and time again.”

            The above is probably the proof why some PMs don’t get any respect from technical experts. You are basically saying then a person with limited or no technical abilities is able to tell when a technical expert is right or wrong on issue related to his/her domain. Don’t you think this is absurd? I mean how can a reporting tool determine the technical difficulties faced by developers in their work?

            Also software development is not digging trenches so you can’t accurately estimate the effort needed to complete a tasks. Estimates in software development have always been a problem and continue to be one as it is not possible to get accurate estimations no matter how good your so called methodology is. That’s because software development is a creative activity and trying to finish something faster will results in a large number of bugs and in technical debt which means extra work.

            But even if the developers do give bullshit to PMs and to other non-technical employees, what can they do about it? Maybe ask for a 2nd opinion from another technical expert but if the 2nd opinion is the same then the non-technical people can’t do anything about it.

            From my experience however I have learned that PMs are not held accountable for the fact that the developers are not able to finish the project in time since they have no control over this matter.

          2. SS

            @adrian83 simple – the developers are part of the decision making process. During the discovery phase, PMs work with the developers to approximate how long a piece of work will take. Ultimately, they have the final say since they are the one’s doing the actual work. Once the developer has committed, they have to deliver as agreed.

            This whole argument a non technical PM cannot measure performance is rubbish, if they take the approach above and missed deadlines happen consistently.

          3. SS

            @adrian83

            By the way, whilst I agree that it is hard to quantify the exact time to investigate and solve a problem it should not be used as an excuse to not get work done in a timely manner. Every successful business operates with tight deadlines, and a good PM can optimise the process so that the team is more efficient.

            It sounds like you are making excuses for yourself when you can’t complete a piece of work quick enough. As opposed to looking at how you can complete it quicker which is where PM comes into play.

            Besides, good reporting tools such as burn down charts measure the average work rate of the developer. If you have ever used one, you can get a good idea of the skill level and speed of the developer over periods of weeks/months based on the type of work that has been completed by the developer. So as a quick example, if the developer is completing 6 points of worth of story points on average over q period of 3 months, then that dips to 3 points for the next period of time and the tasks are similar. It is safe to assume that there is something wrong with the developer.

          4. Adrian83

            @SS

            “This whole argument a non technical PM cannot measure performance is rubbish, if they take the approach above and missed deadlines happen consistently.”

            In software development the speed at which a developer completes tasks does not equal with performance. A developer can finish his tasks pretty quick but his code most likely will be full of bugs and/or will contain a lot of technical debt that will make it very hard to maintain or further develop. Also code written in a hurry many times will suffer from performance issues.

            Another developer may take longer to complete tasks but his code may be more efficient, less buggy, and much easier to maintain and further develop.

            Of course there must a compromise between speed and quality but this is something that technical experts and technical managers are responsible for and not PMs (unless they are also very good technical experts).

            If the technical experts don’t want to compromise on quality in order to gain on speed then there isn’t much non-technical people can do about it. Larger software companies however also have CTOs that are part of the executive management team and take all the high level technical decisions in order to put in practice the company decisions.

            A non-technical PM will consider more productive the developer that finishes the tasks faster not taking into account the quality of the code and the impact the code will have on the future (bugs and technical debts). That’s why non-technical people or less technically competent people can’t really measure performance and usually are not responsible for doing this.

            I am not sure about the way your organization works but I have never seen a PM responsible for the performance of developers, this is usually the job of a software developing/engineering manager and technical leads. Nonetheless PMs could be responsible for developing performance only if the are also technical leads.

    2. SS

      @kp

      Just to add only because you are technical does not mean you can manage people. I have worked with quite a few tech leads when I was a developer and in terms of management they were shit.

      They had great technical skills, but that did not translate to having strong interpersonal, man management and planning skills. Both are needed to deliver a project in a timely manner. Again , please do not offend us by comparing us to ‘glorified secretaries’, yes we need to relay information And report on the status of the project, but unlike glorified secretaries we have to do a lot of planning to make sure everything is delivered on time managing cross functional teams. A secretary will never have this level of responsibility and experience the level of stress that comes with this ever!

      Reply
      1. Adrian83

        As I said in a previous comment project managers, as a general rule, don’t manage people.

        Managing people involves:
        – hiring an firing employees,
        – managing the work assignments of employees (for example on which projects they should work),
        – providing technical leadership and guidance to employees,
        – taking high level technical decisions,
        – evaluating the professional performance of employees and taking actions to improve it,
        – managing the employees rewards system (pay raises, bonuses, other benefits)
        – sanctioning the employees for wrong doings.

        Employees who are not themselves managers are managed by low level managers (also known as first line managers). These low level managers, as a general rule, don’t manage projects and don’t work as project team members instead they supervise the work of their direct reports no matter if they work on projects or not. Some low level managers have a budget at their disposal so they can act as project sponsors.

        Also the low level managers in most cases are promoted from among technical experts as they do need their technical abilities to perform their work. If you are not a technical expert yourself how can you decide who is the best candidate to get hired to work in a certain technical role?

        In small companies there may be no low level managers which means that the technical experts may report to someone that has not technical background, or does have a technical background but in a different domain. The above rule usually applies to larger organizations.

        Reply
  19. Cal

    I am currently studying a Project Management module in College and all I can say is, hell will freeze over before I ever become a PM. Quite simply it would be my idea of hell.

    Reply
    1. underrated

      Then why are you studying that shit? Use the money to study something more respectable and actually useful to companies.

      Reply
      1. SS

        I bet you have never worked in a company that has no serious project management or none at all to make that remark. Like any profession there are good and bad project managers, that’s why digital people hire them.

        Reply
        1. underrated

          Lol, a housewife with 2 kids does more project management at her house. No studying required.

          Reply
          1. SS

            You know right that there are different styles of PM, Prince 2, Agile methodologies etc and the hard part is knowing what style of PM to put in place so that your organization runs smoothly? You clearly are a moron to be honest if you can’t see the value of good PM with helping a project stay on track and within budget.

      2. Cal

        Because it is a module in part of my overall major.

        Reply
        1. underrated

          I bet that is the one class during which the students relax, sleep in class, or answer WhatsApp messages on their phone, because they need to be save their energies for actual Computer science subject classes like Data structures or Compilers.

          Reply
          1. SS

            Right, because the ONLY skill to run a successful IT organization are technical skills – what about keeping everyone motivated and being able to get non technical and technical teams to work together to deliver a project on time?

            You my friend are a moron, and this is coming from a comp sci grad, that was an ex developer and now a PM. I can just tell right now that you would be an absolute nightmare to manage from putting people whose roles that you feel are unimportant down.

          2. Cal

            True about most my class sleeping. I’m voming from an experience of also having worked on projects in the past, and from what i have seen Project manager is the most undesirable job in a workplace. No way I could ever do it, becoming the most hated person in a workplace isn’t worth it.

          3. SS

            If they are the most hated people in the work place then they are not very good from not gaining respect of the team they have managed. I have a lot of respect from the team that I am managing, since I make them feel very involved in the decision making process with upper management from voicing their concerns.

            You guys need to stop generalizing, it’s like any profession, you have good and bad PMs. The good ones will have your back and shield you from corporate politics so that you can then focus on writing code without getting dragged down.

          4. Cal

            As said it’s my experience. My experience is that PM’s (that I have worked with) are the ones ready to bask in the glory of a completed project but when it’s delayed they are the ones to come in and tell you “Weekend’s canclled guys, overtime for everyone – or else”

          5. SS

            You know what, that does happen, no doubt. But again, they are not very good PMs if they can’t plan the project and resources properly to ensure things get delivered on time. This is arguably the most important part of the role, and the whole point of being a Project manager to introduce processes so that work is delivered smoothly. Overtime is a massive red flag, and it is a sign that the planning was inadequate as well as expectations not being properly managed before the project begun.

            At the company I work in, when a project is going wrong, I am the first one responsible for this. If it turns out that the project is delayed, because a member of the dev team is not pulling their weight around, then that is another story altogether. I have in the past worked with subcontractors who did exactly that, and we quickly found out through having good reporting tools in place (another must for any decent PM).

          6. underrated

            ” they are not very good PMs if they can’t plan the project and resources properly to ensure things get delivered on time. This is arguably the most important part of the role”

            Lol the way they do this is to ask developers how long a task will take, maintain a spreadsheet with cells that are colored red, yellow or green, then keep disturbing hardworking developers every day or so asking the status, and whether they are going to meet the timelines THEY came up with, and update the color of the spreadsheets. I could easily write a few lines of Perl script to emulate the work of a PM. Or train a chimpanzee to do that work, just for the lulz.

          7. SS

            What you are describing is the classic waterfall project management, where the reporting is built around GAANT charts that is based on approx time. GAANT charts are often inaccurate since your forecasting is based on a developer opinion on how long something will take and not past performance as you have just found.

            Any decent digital PM uses agile methodologies to run digital projects, where forecasting is based on the historical work rate of your developers (and team) breaking down work into user stories with story points allocated to them. Obviously, yes it helps if you are technical, but the role is much more about optimising team performance so that they are able to produce high quality work efficiently and consistently. The PM role in the whole process is to support the team, not get hands on and deal with impediments as they arise, ensuring the process is being followed. They also act as an interface between the stakeholder and the rest of the team. This means your developers can get on with coding and not be worried about being dragged into meetings talking about operations and strategy.

            Anyway, I still stand by my point, you have just worked with shit PMs from the sound of it.

          8. underrated

            ROFL ok for what you described above, a few more lines of Perl code. You are redundant. ROFL.

          9. SS

            Such a moron, really are.

            Pearl won’t solve your problems when the team loses motivation to work, and thinks you’re an arrogant dick.

  20. underrated

    I love thrashing this PM guy online, for all the years of abuse I faced under PM after PM in my career.
    So for the stuff you mentioned, in addition to my Perl code I could create a new role called mother-hen, hire a motherly looking woman, will sit in a “hugging room”, and employees could walk in and get a hug.
    That is better than having these PMs trying to play a mother hen.
    ROFL.
    But seriously, we engineers faced tough engineering entrance exams at age 16 before joining college. We don’t need no empathy at work. We are self-motivated and are tough as nail.

    Reply
    1. SS

      You seem to forget that you are talking to a CS major which is why your arrogant engineering comments piss me off, I studied all your modules and coded professionally for a while.

      You’re also deluded if you think management is so black and white – take a look at me and you right now, we are bickering because we have a different outlook with how things should be done. I.e. You are downplaying the importance of a PM, whilst I am not. Now imagine that situation in a company where you need to manage stakeholders, the team expectations so that they all follow the same page so that everyone is happy and it gets delivered properly. In short interpersonal, and leadership skills are not something an engineering class teaches you, either you have it or not. Since a company comprises of NON TECHNICAL people as well, it doesn’t always come down to how technical you are. The fact that you are so blind to this, goes to show that you lack leadership, communication skills and are a pure techie, hence why PMs have a job running operations.

      Anyway, I have nothing to prove, just yesterday I found out that sales have increased by 60 percent from my delivery skills. Previously, they were taking your retarded approach and just having technical people with no project management experience run the show.

      Reply
    2. Adrian83

      @underrated:

      My personal experience with PMs has always been very good. They have always been friendly and many times show humility towards the other project team members.

      With the exception of the less complex or internal projects I believe that PMs are very important for the complex projects that are being delivered to external customers. Trying to deliver a complex project to a customer without a dedicated PM is not impossible but it is very hard and very inefficient.

      I am not trying to demonstrate that PMs are useless but I don’t like it when many of them are telling lies, usually on the web about the actual work that they are doing.

      Many PMs claim that it is their merit that the project is being delivered in time and within budget but this is obviously a lie since they don’t contribute to the actual work being performed. What they are doing actually is helping the project team members to deliver in time, but they can’t do anything about it if the team members can’t do this.

      They also claim that they are managing people. Managing people however involves hiring and firing employees, managing the employees work assignments (for instance on which projects to work), providing technical leadership and guidance to the employee, evaluating the performance of employees and taking steps to improve it, managing the employees rewards system (pay raises, bonuses).

      PM usually have none of the duties above, what they are actually doing is managing the tasks that have be performed by ensuring that the tasks are being assigned to a team member or group of members and then monitor and report the progress. They also deal, or should deal with any non-technical issue that impacts the team.

      They claim that they are planning the project but in reality all the information they use for planing is being provided by the other team members. If the other team members provide poor information then the whole planning will be poor and unrealistic.

      They claim that they are motivating the team members but actually can’t do this since most of them have no power to give raises or bonuses. Of course money is not everything, employees can also be motivated by other means but it is hard to motivate someone to do something without giving him/her any material benefits.

      Also many PMs consider themselves more mature than the other team members as if they are some sort of coaches or mentors. That’s again untrue since team members want from their coaches direction on how to perform their duties, something that most PMs can’t provide.

      The biggest benefit that PMs bring is stakeholders management meaning that the PMs most be some sort of mediators capable of getting all the stakeholders involved in the projects to work together in an efficient way. Dealing with the customers is equally important and in average PMs are much better than engineers when they have to face the customers directly.

      Reply
      1. SS

        @adrian83, if you are referring to me, I am actually doing most of that in a support capacity. Being Scrum master I need to track progress, report the status of sprints (to stakeholders), and generally act as a support mechanism. Then again, I am working at a small company so probably doing a lot more than your bog standard PM. Yes, indeed when a project is going peer shaped I am at the mercy of the technical team, which as you have correctly support need to relay this back to the client as painlessly as possible.

        Reply
        1. SS

          I also do a hell of a lot of planning working with both the technical team and stakeholders. I don’t implement the features, but requirement gathering and maintaining a product roadmap is.

          Reply
          1. underrated

            Ok this guy is a Program manager, to use the terminology in my company. Such people do some useful work as he says and don’t have any reportees under them. They are not the scum persons, and work alongside engineers without being involved in their performance appraisals.
            The scums are the Engineering managers, specifically the ones that are non-technical. They will either do the same overlapping tasks with Program managers (or just steal their reports), or no work at all except playing mother-hen and shit, and the most preposterous thing is they are involved in performance appraisals, and give employee ratings purely based on who are their favorites, for they have no frigging clue about the actual work. These bastards should be fired, they bring a huge huge value to the company, with a negative sign in front.
            IMO Program management is fine as long as they are not also people managers with reportees. But Engineering managers should do engineering or not exist at all.

          2. SS

            You are so angry towards PMs, as a matter of fact I have got nobody fired after a year doing it, everyone I have ‘managed’, has ended up becoming better more productive developers, they have all also given me glowing recommendations on Linkedin. I do not also intervene with how technical teams do their works, as long as when they commit, they help me deliver it. Hence, they have a lot of say at the time on the initial planning, whether the work is realistic or not during the time frame. My role is basically to ensure everything is organised, and processes are followed (from top to bottom – non technical and technical). I do also come from a technical background so do provide technical support if needed from time to time. Recently a developer was stuck on a javascript problem involving callbacks, I helped him out.

          3. SS

            @underrated – sorry misread it yes I am more of a program manager, or product manager as they put it. I am more interested in operations as a whole and making sure every one is happy and we are respecting the product roadmap for x quarter, y quarter etc, as opposed to caring about how developers write code etc as long as when they say they will commit to doing something they deliver. If it turns out after they have committed, issues have arose during the release cycle, instead of getting the guy fired, I escalate it to upper management, and produce a status report why we are having trouble delivering it. Sounds easy right – but it isn’t when you are dealing with aggressive impatient stakeholders. Account management is only easy when things are going smoothly.

            I also have to do loads of other paper work such as producing a product road map so that stakeholders have a clear idea of how things are shaping up, requirement gathering (writing the user stories and acceptance criterias for the developers etc), research ways to help the product be more competitive etc etc It’s a lot of paper work – a developer can do this too, but it is a job in itself.

          4. Adrian83

            @underrated

            Now I understand your problem. You have no issues with project/program managers but with functional managers.

            Most companies operate under something known as the matrix organization. What does this mean? It means that all the employees are assigned to teams according to their line of work and function. For instance all the Java developers from a company or department may belong to the Java Team. QA Engineers may belong to the QA Team and so on. The head of such a team, or a group of related teams is known as the functional manager.

            The activities performed by a company however require that workers belonging to different functional teams to work together as a so called cross functional team. For instance in a software project business analysts, architects, developers, and QA engineers need to work together as part of a team. These cross functional teams are typically temporary in nature (they only last for the duration of the project) and are being managed by project managers. The membership of the team can also vary depending of the project’s need.

            Project managers however don’t manage the people that are working on the project teams but instead they manage the tasks that have to be performed, defining them, ensuring that they are being assigned and reporting the status to both management and customers. They also manage the communication between the different components of the team as well as between all the stakeholders involved in the project. Sometimes this is know as managing the operational aspects of a project. PMs generally don’t manage the technical aspects of a project.

            Project managers however, as a general , rule are not superior to the other team members and they have no formal authority over them. PMs are just ordinary employees (not managers) with no subordinates. PMs don’t have the power to hire of fire employees, give them orders, do their performance appraisals, or manage their rewards system (pay increases, bonuses).

            All of the above duties belong to the so called functional managers. An Engineering Manager is a functional manager for a team or several teams of engineers. The functional manager manages people and he/she is the boss while the project manager does not manage people and he/she is not a boss.

            As a general rule functional managers should come from the same line of work as their subordinate employees. For instance the functional manager of a team of developers should be a developer too.

            It appears that your company has appointed functional managers that are not from the same function as their direct reports, that is engineering managers that are not engineers. This is not typical as in most companies engineering managers must be engineers. If you look at job adds for engineering managers you will see that in almost all cases being an engineer is a must.

            So you have issues with managers that have formal authority over you but are not from the same line of work as you are. These are typically not project managers.

          5. Adrian83

            @SS

            Effort estimation in software development is something very inaccurate as developers are only able to truly appreciate the complexity of a task while they are working on it.

            When you give a developer a task he will try to imagine what needs to be done to complete it and then he will rely on his/her past experience to come up with some estimates to which he/she will add a safety buffer.

            A task however may have a lot of hidden issues that will only come up to surface after the developer has started working on it. If the buffer can cover these issues then the developer can finish on time otherwise he will finish later.

            Also a task may involve working with some frameworks or APIs that the developers has never worked before. This will make the estimate even more inaccurate.

            In conclusion developers can’t really commit to some deadlines for completing tasks as they can’t come up with an accurate effort estimation. In order to complete in time developers may write poor code that will result in a large numbers of bugs, poor performance and a lot of technical debt that will make the code unmanageable in the future.

            If a developer hasn’t finished a task in the time he said he would it does
            not mean that he is a poor professional that has to be fired.

          6. SS

            @Adrian effort estimation is not supposed to be accurate, but when done right you can measure the complexity of something relative to another based on the developer technical ability, which makes it more accurate than forecasting via a gaant chart which is based on the time something that will take. I was a former developer, so lets compare the following examples

            Task:

            I want ‘hello world’ printed in the screen on bold

            This is easy right:

            hello world

            to

            Task 2:

            I want a button, when you hover over it, it becomes twice it’s size and turns from black to red.

            Now I don’t know for sure how long both tasks will take, I am going to guess, but I can compare both tasks, and know obviously task 1 is much easier than task 2, so I am going to allocate it less story points to task 2. Eventually, this approach is going to form the bases of my sprint planning, once I get an idea of how many story points on average a developer can complete in a week. So if I am consistently finding on average they can only complete 6 points worth of stories a week, I am going to plan my sprints based on the above approach and put 6 points worth of tasks in there.

            When you use the above approach in a sprint setting, you quickly get an idea of what the developer strengths are weaknesses are. i.e. for example, you may consistently see a developer might find some tasks easier than other – I once worked with a developer who just found front end tasks harder than backend tasks from under developed Javascript skills. Hence the developer is really involved in this process and has a say how ‘complicated’ a task will be, if the developer cannot estimate at all, then the problem is often because the task is too large and not broken down into small manageable features. Which is something that I often have to do for them.

            As an example a stakeholder could request that they want a report, where you can sort the columns, is ordered alphabetically, has pagination, and can be exported in .pdf format. The first approach could be to tell the development team how long it will take, and then expect them to deliver it in the timeframe they said they would. The second approach, and the more agile way, is to break down the requirement into pieces. Once you have done that, the team can then more accurately figure out the effort needed to implement each individual component, and then give a more accurate forecast to the stakeholder based on how many sprints are needed to implement, and test it. So…as a point, it all comes down to planning in the end, and not technical skills, knowing how to write good user stories is a skill in itself.

            Your point about software development is false where it is impossible to estimate tasks, although there is a level of investigation needed, overtime when you have seen the problem before, with experience you have a much better idea how long or complicated something will be.

          7. Adrian83

            @SS

            You approach is very simplistic and ignores a lot of crucial factors that usually come up when you are estimating the effort needed to complete a development task.

            For instance, while I was supporting the applications of a customer a change request had come up for adding an additional report to an existing one. The existing report was triggered every weekend it was doing a very complex database query and then it was sending the results by email to all the users. What I had to do is add an additional query to the existing one.

            At first sight the task looked easy to do, writing the code that would perform the query was straight forward. Since this was a task with low complexity the effort estimate should have been low. However, when I had started working on it I discovered that the existing code was extremely badly written which made it very hard to read and understand, and very hard to extend to add additional functionality. So, this was no longer a task with low complexity.

            I took the drastic decision to refactor the whole code by rewriting it from scratch to allow it to become manageable. This of course increased dramatically the effort estimate and thus the time needed to complete the task. After I had completed my task new change requests came asking to add other additional reports. Thanks to my code refactoring adding the additional reports was done much faster.

            If your “productivity” reports had been used, then they would have told that my productivity had dramatically decreased because I took such a long time to complete a task that seemed to be of low complexity.

            Also, if a developer works for a long time on a certain part of an application his productivity will increase but if he moves on a different part of the application his productivity will decrease because he needs some time to get used to the new code.

            But what makes software development effort estimation really hard is the creative nature of the work. When you receive a task, you will think on the algorithm and the API methods you are about to use for it but during development you may find out that your initial idea doesn’t cover everything and you will have to adjust it. Also, you can choose to work faster with the risk of creating technical debt, defects and low performance, or you could work slower and create a higher quality product. No matter how good an experienced you are there is also the option to work faster or slower.

            In conclusion, the way you think about reporting, effort estimation and productivity in software development is very simplistic and doesn’t consider some crucial aspects. Your approach is suitable for the projects that involve trench digging or other types of work that are not creative in nature.

            It is perfect normal sometimes for the so-called productivity of the developer to appear as it is decreasing but in reality, the developer is doing an extraordinary job in order to deliver a high quality product. It seems your reporting tools don’t take this factors into account and that’s why they are pretty much useless.

          8. SS

            @adrian83

            It’s simplistic because I used a simplistic example, but we are successfully doing it on a web application that has an API (built from scratch) which feeds data into an angular JS front end and CMS. We built the product in less than a year incrementally.

            The key is to know how to break tasks down into smaller chunks and that requires a lot of planning and investigation well before you touch a line of code. Yes, that means the developer should look at the code base well before assigning story points to the task. This is called ‘system analysis’ as opposed to diving straight in. If you found out that the code needed to refactored after starting the task, that means you just did not do a good enough job during the investigation otherwise you would have found that out before committing to the work from looking at the code base.

            It is also ok if you are not always accurate the point is that your forecasting will be a lot more accurate than if you have not done it. If it turns out you start a sprint and you are delayed because like in this case the initial investigation, and hence user stories were not broken down properly, then this issue is raised during the sprint to your scrum master where the plan of action is to then for the next sprint break the stories down further to manageable chunks. As opposed to committing to deliver everything in one go.

          9. SS

            @adrian83, to expand on my last post, I just feel that you can’t not have any project management – the problem with your whole approach where since you are structuring the project based on very little planning (finding out as you go along) and timeframes, you have literally NO pressure to deliver in a timely manner. Furthermore, right now you can get away with not requirement gathering properly. Hence, with your current approach , you can exploit it and keep on telling stakeholders ‘it took longer than expected because of x and y reason’ from a lack of initial planning. In the end this may work in your favour, since you can dictate the pace work is delivered, but many companies have a product roadmap that they need to respect, and need to minimise delays as much as possible to keep their competitive edge.

            No project management framework is meant to be accurate, but in the case of Scrum, the accuracy improves overtime once you have a better understanding of the product you are trying to build and the capabilities of the technical team. Most sprints are 1 or 2 weeks at a time, that is more than enough time to get a substantial amount of work done. Again, if you have stuck items into the sprint that can’t be done in a week, your requirement gathering is just not good enough since they should have been broken down adequately enough.

            Burn down charts measure productivity, daily stand ups are used to find out impediments once the sprint commences. Impediments are good since they often lead to process improvement which in turn makes the process of delivering work more efficient.

            I can whole heartedly say, that every project I have worked on as a developer where it was run with no structure have ended up always being messy ventures, where:

            A) Stakeholders didn’t know the status of their developments and being met with constant delays.

            B) team of developers slacking or not working in sync with one another, let alone hitting the company goals. They just didn’t care – they had no pressure.

            C) release cycles being delayed , if a startup , company going more and more in the red paying for the delays.

  21. Cal

    Well as I have seen project management or indeed any other form of management, you will be hated by the workforce. It’s just part of the game. As the last PM said

    “Yeah everyone hates me but the job get’s done and at end of the day that’s all that counts”

    Reply
    1. Adrian83

      Only bad managers or bad project managers are hated by the “workforce”.

      I have never had issues with project managers, on the contrary my relationship with them has always been very good.

      However it is important to understand that project managers are not real managers as unlike real managers they don’t have any formal authority over other employees. The project team members don’t report to the project manager but to their line managers. Sometimes line managers can also do project management work but this is a different story.

      PMs don’t have the power to hire or fire employees, don’t have the power to give them instructions on how to do their job, they don’t perform employee performance evaluation, and they don’t decide on pay raises or bonuses. That’s probably why they are generally not hated by other employees. Some of them however may get hated if they bother the employees with too much useless questions and drag them into too many long meetings that bring no benefits to the workers.

      Real managers may be hated by some employees if they don’t reward their best performers properly or don’t allow them to grow in their career.

      Both managers and project manager may be loved by other workers if they perform their duties right. For instance managers that enable the employees to develop their career and reward their efforts will be loved. Also project managers that take care of most of the non-technical issues of a project allowing the workers to focus entirely on the technical aspects are also going to be loved. :)

      Reply
      1. Cal

        I am yet to work for any manager I didn’t hate. I’ve always maintained a distance, and view it as: If I don’t hear from a or seldom interact with a manager, all the better.

        Reply
        1. Adrian83

          @Cal

          Are you talking about project managers or managers with formal authority (such as engineering managers)? These are completely two different categories of mangers with different duties.

          The project managers I have worked with were not real managers (they were not part of the management team) but ordinary employees and they sat at the bottom of the hierarchy. Some of them were not even permanent employees, but temporary employees or freelancers or contractors or consultants working for a consultancy.

          These PMs had absolutely no power over me, other than formally approving the work the team has to work on. But they were usually approving the work by ensuring that the work is going to be payed. They were not involved at all in defining the work than needs to be done, in estimating the effort needed or deciding what exactly needs to be done. Their only obsession was for the work performed to be part of the project scope and get payed.

          I see no reason why you would hate PMs such as these. Maybe if they bother you asking too many questions or organizing too many meetings that are useless.

          Managers with real authority on the other hand can tell you how to do your job so you can end up hating them if they don’t let you do things the way you want it. But even here I had no issues.

          Reply
  22. Steeli12

    Everyone in this discussion could use a good 3 years of experience in the technical systems side of a commercial construction project.

    Reply

Leave a Reply

* Required