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.

267 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.

    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.

      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.

        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.

          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. Bob

            I’d like to see a building or anything which is as complex go up if just left to an engineering team within a set budget. Everything takes funds to create. If it isn’t money then someones time which equates to money.

            Truth is if you leave a team of engineers, designers, techs, auditors together guaranteed one will step up to manage all the activities as it gets confusing as the team members won’t go out of their domain of expertise to begin to stitch everyones work together. Plus when it comes time to inform the very person paying the bill, guaranteed they will be asked to report on status, that very person who stepped up will then begin to request status reports and aggregate to provide a high-level status to whomever is paying the bill.

            That person is now automatically in the role of a PM.

            Everyone plays a part including a pm. However a PM should trust their team & their specialities. PM’s that get into the nitty gritty details are those that are just doing it due to lack of trust.

        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.

          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


            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

      None of these arguments relate to technical systems installation on construction projects. Agile, scrum, sprint and others running for product, software and update development, force change construction and TI projects everyday. The needs of “product” launch blow construction projects continuously. Product development communities have no clue of there cost impact on construction.

      1. SS

        @Bob, I don’t know about construction, but in digital that is not the case, on this thread many people are wrongfully assuming that all that is needed to deliver a digital project are developers. Ironically, that is probably why many of the developers on here won’t make good PMs, since they view the project lifecycle so narrowly.

        Every serious digital project I have worked on has a cross functional team working on it, designers, developers, business analysts. At which point my role is to put processes in place so that work is delivered on time by each team to avoid bottlenecks. Some projects can become very complicated depending on the size of teams involved, or if you have 3rd party resources working on them sub contractors etc.

        With that in mind, PMs are not there to do the technical work, rather they are a bridge between stakeholders and the different teams ensuring that time frames are respected and each team have what they need to complete their work.

        So more to the point, all they care about is the ‘delivery PROCESS’, and helping the organisation ‘improve’ that PROCESS so that work is delivered on time and more importantly on budget. Agile is one way of setting up a project, but you then have others such as Prince 2, Waterfall etc. To do this successfully, requires a lot of organisational and soft skills, not technical. Using Agile methodologies for example, one of the key things I had to do at my organisation was to coach agile methodologies to C level and non technical/technical teams to ensure that it is being done properly in the project lifecycle. Without doing that, we often relapsed into a waterfall style of working since the sprints were not respected.

        1. bob

          We are in very different areas of the PM arena. My background is also network design, engineering and business management as well as technical commercial construction so my experience in development and projects goes back many years . In my current area of focus our business requires the PM to be 100% financially responsible for the project(s), manage the resources of the project (s) and be the technical lead of the project. Regardless of any grievances employees might have it is the lack of understanding of a companies processes by all participants in a project that is the failure. This is the failure of company upper management itself, not the PM, technical lead or developer. Lack of training in the most efficient and effective company processes and in communications in order to effectively complete projects for all must be gained and paid for in advance. The pressure of time, cost and resources required for project delivery remains completely misunderstood, wasteful, inefficient and very expensive in general in the business community today.
          More often than not in my business the failure is not at the PM level but at the technical resource and company management level. I have years of examples dating back to the late 70’s and early 80’s with commercial and government projects to prove it and it still is pervasive today. I am a former design consultant and business owner and did not allow my employees to be poorly trained and deliver projects inefficiently and with cost overruns. The problem is not with the life cycle of the project but with the failures of the owners and the upper management of the business.

          1. SS


            Our industries are different, so maybe it works differently where you are.

            In IT, don’t get me wrong, having technical awareness is not going to hurt you as a PM. If anything, I do recommend that all PMs make an effort to gain that knowledge since it is then harder for your developers to bullshit you when making estimates. With that said, I do feel that it is overestimated at what level you need to be technically, because chances are even if you do come from that background and move into a hands off PM role, you are going to experience some degree of technical decay anyway – technologies will change, and more importantly you may not always manage projects where you are technically trained in especially in agency environments.

            Furthermore, even if you are technical, there are skills as I said before that are needed to deliver a project outside of technical skills, every product uses designers for example, who create wirefames, prototypes and are skilled in illustrator, and photoshop. By your logic, does that mean the PM needs to be both a developer and designer in order to successfully deliver the project? Yes, it would be nice, but it is not realistic since these are two separate career paths.

            The whole point of PM is to get the right resources and to put processes in to deliver a project in a structured way. In very small teams, a PM is not that important, but if you have a cross-functional large team that’s where it is definently needed. Without structure or good processes in place to get teams from different departments to work together, there will be delays, and the project will go overbudget.

    3. msbob

      The author didn’t say PMs weren’t important, rather that they get no respect. What he did say is that PMs often go out of their way to show they are important, like you did in your response, which gives the PM less respect.

      1. SS


        I did go out of my way, because frankly I have found half of the comments offensive and undermine the work that I do.

        Not because I’m insecure about the value I bring to a company, but because the work I do is incredibly stressful from managing stakeholder expectations and trying to keep my team on track! Having clients shout at you because work is not being delivered at the speed they want is one example of the shit a project manager goes through which ‘happy go lucky’ developers don’t have to worry about and why they should be respected from being a human punch bag.

        This whole thread post is deeply offensive to the whole PM profession.

    4. Ron

      As a developer with 10 years experience my opinion of PM’s is simple: I can do their job but they can’t do mine.

      1. George

        As a Principal Software Engineer with nearly 30 years of experience, my opinion of PMs is very similar. In fact, I do their job as well as my job. They only know how to ask for a status, quite literally nothing more.

      2. Rich

        As a Senior VP who in essence, is a program manager for multi million dollar portfolios, this is the thought process of most developers; thinking they can manage people when it’s most often times much more complex than managing software solutions.

        Fallacy of engineers in their tech bubble.

    5. Darren Richards

      I agree with this wholeheartly. I too am a technical PM. I am lucky because I have a technical background (I was a BRO) which commands respect from my colleagues as well as the engineers I work with. Only this week our best technial engineers had an issue with WIFI that they could not fix. They asked me to cast my eye over the problem and the issue was resolved within minutes. I also fixed the broadband at Glandwr House. There is no member of staff at my workplace that is in any doubt of my talents. I appreciate there are some bad PMs out there too though, I guess it’s the same with any job…

  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.

    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?

  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.

    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.

      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…

        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!

          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


            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


            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


            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


            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. Arrhogahnt

          So glad I can get rid of dead weight. No compassion at all for kids who think they’ve ‘arrived’ just because they have a four year engineering degree. Some learn to see the world correctly. Most do not. 100% of the stubborn debators do not last. Their ‘growth’ won’t come at the expence of ‘the baby’. Feed the baby. Love the baby. Change its diapers. Or, get off.

      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.

    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.

    3. PM Hedonist

      I agree with Jane a 110%. The good PM’s don’t get respect. And the ones’ that get high visibility and praises are the one’s who actually forged it by taking credit of others.

  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.

    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?

      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.

        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.

          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


      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.

  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,

    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!

  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!!

  7. R

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

  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.

  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!

    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.

    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.

      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.

        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.

          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?

    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

    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.

  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.

  12. Adrian83


    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.

    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.

  13. Adrian83


    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.

    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.

  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.

    1. Adrian83


      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.

  15. SS


    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.

  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.

    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.

  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:


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

    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

      1. SS

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

  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?

    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.

      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.

        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.

          1. Adrian83


            “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


            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


            “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


      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!

      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.

  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.

    1. underrated

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

      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.

        1. underrated

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

          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.

        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.

          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.
    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.

    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.

    2. Adrian83


      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.

      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.

        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.

          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


            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


            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


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

            This is easy right:

            hello world


            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


            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


            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”

    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. :)

      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.

        1. Adrian83


          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.

  22. Steeli12

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

  23. JD

    i would have to agree with Adrian33 on the software estimates. We recently moved to assigning the scope risk from the project budget to the development teams and moved from waterfall to agile.

    We deliver fixed price, fixed scope, fixed schedule projects where our customers submit table of compliances. We have to comply and provide software estimates. Now that the Dev teams are doing the estimates, they estimate everything at 500 hours because they do not know the full scope. And as a PM, I cannot blame them. Then there is an internal battle over the price is too high vs please lower the estimate.

    Agile is not for fixed scope fixed price projects (google it, no one in the agile world talks about it). why? because agile essentially acknowledges the variance of software. At the sprint level, once everything is broken down to the 20hr task, yes you have a higher probability of being accurate. But I guarantee you, you cannot do that when you comply to a customer’s one paragraph description of requirements.

    what I have seen in the move to agile is two things:
    1. Better meeting schedules for smaller items
    2. Because the minimum point estimate is 1 which equates to 8 hours in our company, fixing small items get unrealistic estimates when aggregated together. Previously fixing small things would happen because they were one liner, but now these never get done

    And with project planning Adrian is also correct, the plan is based upon input from the technical people. During my PM training, the instructor gave an analogy: ” I am a pilot of Cessnas, do you think I could fly a 747″ The whole class said yes, except for me. He asked why? I said “You would not know how to start it”. and this is the smae for a project schedule, The PM cannot create a schedule as he does not know the dependencies, but the technical people do, so why dont the technical people tell an administrative person and he or she create the schedule? Our PMs do way too much administrative tasks

    I worked as a PM as part of a larger project where there was a Program Manager and I could not figure out what he did all day. Turns out he copied my schedule and had his own and kept asking me for updates. I told him I’d get my assistant to update his schedule based on mine.

    It seems to me non technical PMs spend way too much time doing administrative tasks, and there is nothing a PM can do if the project is behind, except add more people, reduce scope, extend deadline. All which are contrary to the contracted deliverable (fixed cost, fixed scope, fixed schedule). The only decision he may(not necessarily) be able to do by himself is to have the work done with less expensive people (assuming they are of equal quality)

    …and I have been a PM for ten years and I think we are overpaid.

    Back to SS, why do you need to create burn down charts? why doesnt software do this for you automaitcally? All these reports are administrative. I did a test once to see who actually reads my reports. Some of them, no one. All anyone wants to know is if it will be done on time, if the answer is no, what can be done. If the answer is add more people, then someone has to make a decision on more cost.

    And the bigwigs ask “why is it over budget”. answer just like someone else said, “once we got into it, there was more effort”, and then the response will be why didnt we quote it more, then the answer is, sales couldnt sell it at that price. Around around it goes.

    Give me a simple user story. I can quote 1 point or 20 points, entirely dependent on the customer.

    1. SS


      “It seems to me non technical PMs spend way too much time doing administrative tasks, and there is nothing a PM can do if the project is behind, except add more people, reduce scope, extend deadline. ”

      I do a lot of that, and why is it seen as an easy job only because it is administrative? Let’s break that down to what is involved:

      “except add more people”

      The only way you are going to do that is if you have managed your initial project budget correctly, or are given the budget to do so which is highly unlikely since the budget is determined by the amount price the project has been sold at. Baring in mind, when you run most projects, you need to make sure that the company is making a profit, and need to sign off with at least a 50 or 60% profit margin, as is the case where I work.

      Is this technical, no…is this always easy, again no, is this administrative, yes, but somebody has to sit down keep track and make sure the budget of the project is not ballooning. I find this more of an issue when you work with 3rd party sub contractors who charge by an hour than with an in house team.

      “reduce scope, extend deadline.”

      Ok again, the process of getting either done is to talk to the client, explain the situation and hope that they agree with you. What if the client is hostile and doesn’t care, what then? This is where it can become tricky. Again, not a technical skill, but account management. Maintaining client relationships however is extremely important since it can lead to more business which impacts the companies cash flow.

      Ironically, these 2 things you have mentioned is arguably why a lot of companies hire PMs and pay good money for them. When you have a good PM and they ensure both are done properly, it helps the company generate a great deal of money since projects are signed off smoothly with good profit margins leaving a happy customer and more business down the line.

      I am sure as a project manager, you have also managed a team of people to deliver a digital product at some point, designers, developers, testers etc all with different personalities and egos. What do you do if one person in that chain is a bottleneck? Are you going to expect you developer to go to the designer and tell him to hurry up? That is where it can be hard, and where I disagree with technical people such as Adrien is that they seem to think that they are the only people working on the project. Yes, if you are the only person working on the project, and nobody else then it is easy to manage since everything is down to you.

      “1. Better meeting schedules for smaller items
      2. Because the minimum point estimate is 1 which equates to 8 hours in our company, fixing small items get unrealistic estimates when aggregated together. Previously fixing small things would happen because they were one liner, but now these never get done”

      a) Scrum which you use story points for, is not based on time, but the complexity of each task relative to each other, and you measure complexity based on burn down charts which is based on points. So when you say 1 points = 8 hours, that is not a great way of doing things. It should be this task is 1 point, the other task is 2 points, because from experience we know it is easier to complete than task 2.

      When I plan my projects, I work out the average number on points the team can handle in a week, then base further planning on the average. You do not find this out until after 2-3 sprints from reading burn down charts.

      If small things crop up that are not completed, I then have to sit down with the stakeholder and tell them the situation and more often than not those small tasks form the bases of the following sprint.

      b) There is software that automatically generates burn down charts for you, but you still need to know how to analyze them to optimise the productivity of the team. That starts with knowing how to use story points efficiently. Ties in with your earlier question.

      c) Fixed scope projects, with set deadlines don’t work well with Scrum, but you can run them in an agile way using Kanban. I would argue though if they are fixed scope and you have had no say in what the deadline will be, then it might as be classed as a waterfall project. The whole point of Agile, is so that you can deliver your projects less rigidly not set by an unrealistic deadline.

      d) It is fine if the developers estimate how complex tasks are, I find where I am needed the most especially with product management, is helping the stakeholder scope their work properly so that only features that bring the most business value into their product are prioritised first. This is not technical, and involves knowing how gather requirements and write user stories, then prioritising them which goes onto form a product roadmap. If done well, your stakeholder will be happy since their expectations are managed from knowing what to expect from the upcoming developments.

      e) Finally, yes, being technical helps immensely. I come from a web development background, I often use that knowledge when communicating with technical teams.

      The more technical you are, the better PM you are going to obviously be, but at the same time where I disagree with Adrien is his idea that they need to be a specialist in that particular thing. As long as you understand what the problem is, how the technical team are going to try and achieve it on a high theoretical level. As a PM, I think it is important that you understand software architectural patterns, APIs, MVC, Server-client architecture. Knowing how one particular programming language works does not matter, that is for the developers to care about.

      1. JD

        with respect to this:
        d) It is fine if the developers estimate how complex tasks are, I find where I am needed the most especially with product management, is helping the stakeholder scope their work properly so that only features that bring the most business value into their product are prioritised first. This is not technical, and involves knowing how gather requirements and write user stories, then prioritising them which goes onto form a product roadmap. If done well, your stakeholder will be happy since their expectations are managed from knowing what to expect from the upcoming developments.

        we have people, BAs , product managers, and architects who do this as they understand the customer’s business and the value it may or may not add. The only thing I can do is say, we are running behind, can you please prioritise. which then means I am reducing scope, or am now forced to deliver some now and some later, increasing my cost. As we moved to Agile, we discovered we now have a huge deployment, test, retest, do it all again cost, because it is all so fluid.

        WRT to points and hours. At the end of the day people get paid by the hours they work and we have to quote to customers in dollars. if you estimate in points, there must be (and is) a correleation to hours/dollars. I know agile hates to talk in hours, but everyone will admit at the end of the day there is a correlation to hours. For us it is 1point is 8 hours. The complexity comes in in that they are not allowed to estimate, say 7 points. It is always(and I cant remember the exact sequence) 1,2,4,8,20,50. but as I say the small item problem is still there as they cannot estimate 0.5 points. so if I have ten one liners, they get quoted as 10 points or 80 hours, where before, we just would have fixed them in a day or two by the time we tested it.

        That being said, I noticed now internally we estimate in hours for bugs, and estimate is broken down into investigation, fixing, testing, but all in hours

        I was going to tell my story on why meeting the estimates can be so wild. I had the exact same dev team working on the exact same technology, but for two different customers, and with different features to augment our existing application. One came in at 50% margin, and the other at 12%. Why? Customer definition, customer expectation (my favorite “every good software should do xxx” or my other favorite, you show 3 decimals, anyone who writes software in this industry knows to show one decimal from that type of quantity)
        and they simply will not pay until it is “fixed”. A customer with no internal need to meet a schedule date is the worst customer

        Analogies are generally bad, but I give this one, if you ask me to paint the room blue, and I paint the ceiling blue, is that what you expected? what about the baseboard? door handle? shelves?

        or the other easy analogy. The user story of : As a person who counts cars, I need a tool that I can add the number of cars as they go by. How many points?
        Well, there is no definition of font size, no definition of it this application can run on top of another, no definition of errors, no definition of colors, no deinfition of whetehr or not a history needs to be manintained. could be anywhere from 20 points to 1000 points

        The good news is you average all of them out and the company is close to the desired margin. The bad thing for us is if you end up with a few bad ones, you have a bad year as ours are large and not enough to go through enough to average out in a shorter time period

        1. SS


          I can see a few problems here:

          1) In your case, story points does not seem to be being used in the right context. It sounds like you are substituting hours by points for projects which have short delivery cycles i.e. need to be delivered in hours as opposed to a period of weeks/months. There is nothing wrong with associating time with story points as long as it is loosely done, for example for 2 points I’ve allocated a day to it, for 1 points half a day etc.

          In your case, and if story points is being used how I’ve assumed it is, you are better off organising your project using Kanban and not Scrum which uses Story points. You can then measure productivity using ‘cycle time’ i.e. the time it takes to complete a requirement based on the time it took to complete it. This is another agile methodology, but more in line with waterfall I guess.

          I have found that the real power and benefit of using story points is when you have structured your project integrating Scrum. Projects that benefit from Scrum are typically those that do not have to be delivered immediately but over a period of months/years.For those projects, the idea is to deliver the project scope incrementally in weekly or fortnightly sprints, where the work for each sprint is planned before the start of every sprint according to the what gives the most business value for the stakeholder at that particular time, and the work rate of the team is measured using burn down charts based on the story points allocated to the tasks that comprise the sprint.

          A real life example of the type of project that benefits from this approach, is when you are tasked with the on-going delivery of a new product to market, since an attribute of product management is on-going development of the product based on new ideas that appear overtime.

          It is worth noting, as every project is different, the velocity of the team on one type of the digital project is not necessarily applicable to another, given that every project is different. So it should be expected for the first few weeks, that the teams will fall behind on the burndown charts whilst they get used to the project. The way to handle this, is to decrease the total number of weekly story points until they hit their target, then gradually increase as they become more comfortable. After that initial hump, it does become easier, with more accurate forecasting as a result.

          The end goal by doing things this way is that once you understand the teams velocity for that particular type of project. You can then give a more realistic time estimate of when things will be delivered rather than plucking a figure from the air and saying ‘it will take 3 hours’ since your forecast is based on what the team can do from experience as opposed to what you think they can do. That’s why I would never use hours to specify the time needed, but measure the deliverable based on the number of sprints it needs which is a lot better way of doing things given the time needed to implement, test, QA, release.

          If put in a situation where I need to deliver work based on hours, I would not structure my project using story points and scrum.

          WRT this point:

          “I was going to tell my story on why meeting the estimates can be so wild. I had the exact same dev team working on the exact same technology, but for two different customers, and with different features to augment our existing application. One came in at 50% margin, and the other at 12%. Why? Customer definition, customer expectation (my favorite “every good software should do xxx” or my other favorite, you show 3 decimals, anyone who writes software in this industry knows to show one decimal from that type of quantity)
          and they simply will not pay until it is “fixed”. A customer with no internal need to meet a schedule date is the worst customer”

          The problem here is not story points, agile it is bad requirement gathering. That is not your fault, your BA is not doing a good enough job and causing you to struggle with project delivery. If S/he did, you would know exactly what needs to be delivered, which brings me to your next point based on the analogy:

          “Analogies are generally bad, but I give this one, if you ask me to paint the room blue, and I paint the ceiling blue, is that what you expected? what about the baseboard? door handle? shelves?”

          Good user stories should have user acceptance criteria’s which covers what the end user expects from that ‘story’. In this case, the user story would be:

          As a user, I want my whole room to be painted blue, so that it is a different colour’

          User acceptance criteria for the above story will be:

          – Ceiling must be painted blue
          – All of the walls must be painted blue, there are 4 walls
          – The wooden door must be painted blue

          and so on. If the user acceptance criteria has been fulfilled, then the story has been completed.

          Where it gets tricky however, and I think that this is where you might be struggling is not only from a lack of user acceptance criteria, but from the stories not being broken down properly. So using a software development example:

          “As a user, I want a report which displays people that have registered, so that I can see who has registered”

          That is not a good user story, because it doesn’t tell you what the sub features of the report are. i.e. can the user sort the rows in the report by column? Can the user export the report etc, if so , which format? So for argument sake, lets say the client wants a report which displays all registrations, where as sub features you can export the report and order it by columns. You would create 3 user stories:

          Story 1

          As a user, I want to see a report table which contains all registration data, so that I know who has registered.

          Story 2:

          As a user, I want to be able to sort the entries in the report table by column, so that I have more than one way to view the data

          Story 3:

          As a user, I want to be able to export the table in the report in pdf format, so that I have a copy of the report.

          When you do this, it then becomes easier to allocate story points since you have sliced the functionality into smaller chunks.

          1. JD

            I will try the kanban, sounds promising.

            I do think you may have missed the point on the scope definition. We have two types: 1.we have to comply to table of compliances, where there is no(or very simple Q&A) negoitiation on scope.
            2. where we work with the customer to get user stories, usually by a BA, product manager, architect (not the PM)

            1. is problematic simply because the specification is usually abstract, but the customer will continue to say “this is your busniess, you should know what this means”. I wont go into that one

            2. is where we think we should be good but this is where I suggest the customer influence and agile(or maybe just software requirements in general) is lacking.

            Take your example of a report. I dont see a user story for how many pages it is. I dont see criteria or a user story for what happens when the person’s name is 70 characters but you only have space for 50? Excel has two options, cut it off or make the font smaller. When your developer makes the report has has two choose one of these. why isnt it in the user story or criteria? The answer: Because the BA did not think about it(because he is not the developer), and that is my point. no one thinks about everything. And some customer will not care or not have that problem. And that is the variance in the software estimate

          2. SS


            From what you have written, I feel that where the whole problem is stemming from is the requirement gathering and how it is being done. It just sounds like the user stories the BA is writing is not detailed enough, and this is having a knock on effect on your ability to deliver work from not properly understanding what the customer wants.

            I am a digital product/project manager where I currently work, so I do all of the requirement gathering which helps a lot.

            WRT this point:

            “Take your example of a report. I dont see a user story for how many pages it is. I dont see criteria or a user story for what happens when the person’s name is 70 characters but you only have space for 50? Excel has two options, cut it off or make the font smaller. When your developer makes the report has has two choose one of these. why isnt it in the user story or criteria? The answer: Because the BA did not think about it(because he is not the developer), and that is my point. no one thinks about everything. And some customer will not care or not have that problem. And that is the variance in the software estimate”

            It was a basic example, so I did not bother going into that much depth. But if I was doing it for real, I find that the best way to requirement gather is to start off with creating mock ups of the application working with a UI/UX designer, present that to the client and break each functionality into user stories which has low level user acceptance criterias. It’s the BA’s job to ask as many questions as possible so that nothing is missed out.

            Once the client has approved the mock ups, it should be documented in a statement of work report, so that if later on the client asks for something beyond what was agreed, you can always remind them that it is not in the project scope and not initially agreed, but if needed can do it for an additional cost of x amount. A PM has to cover their back at all times, it is as you have said a highly political job which is what makes it hard. On one hand, clients are going to always push their luck to get work done for free, and then you have the battle of your team not doing their job properly – the BA for example.

            Finally, to do agile properly, the whole company needs to run in an agile way, not just you. Not being able to negotiate project scope, with other people setting deadlines for you (from the sounds of it is happening) is not working in an agile way. The whole point of agile is the very definition of the word ‘agile’, to be able to adapt the project based on changes to the project scope at any point. Either by decreasing on increasing the scope based on the time remaining.

            If the scope is defined and you have a fixed time frame, then you might as well forget running your project in an agile way but stick to the waterfall approach and use gaant charts.

  24. JD

    i guarantee you, you or the well heeled BA will miss the 70 character problem, or the fact that there are 25 rows in a daylight savings day, or that it prints on two pages when I select printer x.

    This is my point: If the code written has 100 if else statements, then the user story must have the same number. The reason: Because the developer is making a decision. And if there is no user story, what is he basing his decision on? If you are like us, it’s what the last guy did in a similar situation.

    Who says that is what the user wants?

    The mockups are good, and we have done many but they for instance don’t tell you the 70 character problem or if the sum and avergaes at the bottom of the page are rounded before summing or summed and then rounded. They dont tell you if the time has to be corrected for timezone. They dont tell you if timestamps represent the top or bottom of period. They dont tell you that the titles need to change for language when I am reporting on a person from a different country

    What does this mean? This means you will have deficiencies which are not documented in the requirements. You will say, well the client didnt tell me, and the client will say you didnt ask.

    You will win some and you will lose some, but in the end the variance of the software delivery is still there.

    unless the developer checks all of the possible error conditions and code paths with the customer, there will always be a variance. And I gurantee you, the customer, nor the BA know all the code paths and data variations

    1. SS


      “What does this mean? This means you will have deficiencies which are not documented in the requirements. You will say, well the client didnt tell me, and the client will say you didnt ask.”

      It is the clients fault if they didn’t tell you, not yours. You should charge them for it, otherwise if you go down that path, they will just end up taking advantage of you from keep on using it as an excuse. I once worked with a client that did that, then stopped once we started charging them for every little thing.

      It is always a good idea to send them a copy of the statement of works before any work has begun so that they can read how the requirements have been documented.

  25. JD

    so, does your SOW state all of the above? i.e. peoples names will only be allowed to be printed up to 50 characters and we will truncate the left most characters until they fit? If so, great, but I’ve never seen it.

    And it is the clients fault if you assumed 50 characters if you didnt tell them?

    My client would say, why did you assume 50, his birth certificate has 70, I’m not paying because you decided 50 was a magic number you pulled out of the sky. now if you told him you only do 50 and even better asked him to check his data to see if 50 would work, then he will praise you for knowing “his business”. If you charge him for everything you did not document about your assumptions, he will not come back to yo as he would rather work with someone who “has done this before” and seen these types of things.

    1. SS


      Again, if the client did not tell you that you have every right not to be held liable for not doing it. The whole point with sending them the SOW before starting their work is for them to double check that nothing is missing. If they double check and then bring it up later then that is not your problem. If your company makes it your problem, then I’m sorry to say they are a terrible company to work for. Where I work upper management takes my side in these circumstances.

  26. SS


    It shouldn’t be about knowing his business, you are there to deliver something for the person based on what they tell you. If with mock ups , and sending them SOW they are not specific enough that’s not your problem. You can’t let clients take advantage of you by doing more work than what was originally agreed for free which ironically impacts the company you are working for cash flow negatively since they can make more money charging for it.

    In my experience anyway a lot of the extra work are small tweeks anyway which do not take a lot of time to do.

    1. JD

      wrt to:
      In my experience anyway a lot of the extra work are small tweeks anyway which do not take a lot of time to do.

      I would agree that is probably true 75% of the time, but it can also be death by a thousand cuts.

      One thing you seem to be missing is, if you did not document it in your SOW, it doesnt mean the client agreed to whatever you assume is not in there. To have a very bad example, if you buy a home off the plans and read the spec sheet to make sure all the trim and colors are correct, and the builder leaves all of his garbage in your house before you get it. Are you going to complain? And do you think he will say, it doesnt say that in the spec?

      thats my last comment!

      1. SS


        As I said you should get your client to review and approve your SOW before beginning implementation. Then if there is anything missing and they complain, it’s not your problem!

  27. G

    There is a reason why project managers do no longer exist in agile methodologies : because in such methodologies, you can’t hide bullshit and what is useless to the project, and team. The emperor is naked there.

    There are no agile project managers. That does not exist. Once you go Agile, the project manager no longer does exist. Because the developers together replace it.

    You get a scrum manager, which job is to SERVE the developers. It’s a total reversal of what a project manager could have been in the old “grand-dad” waterfall method where 80 % of projects failed or failed to reach objectives.

    100 % of project managers I have met :
    – make me lose my time by explaining them stuff they don’t need
    – keep asking “how much time wil that take ?” and can’t understand it’s a temporary value than can go down or go up dramatically (you can’t predict the future, no one can, so why ask me to ?)
    – so clueless they come see me and ask “what can i do ?” well, do nothing. so I can do my job uninterrupted, how about that ?

    We’ve gone agile, fired all project managers, we have 0 now.
    We have scrum managers, fire and forget drones I use when I need something from another team, whatever, that is “blocking” the development process and they handle it while I do my job. They either do nothing and wait, or I ask them to do something : hey ! I need data X but it’s not in the database ! can you please go check the DB people so they either add data to a table or give me a new table with data ?”

    1. SS


      To be honest, I think that you are extremely harsh towards Scrum Masters, yes they are there to support you and get pieces of work from other teams, although I am surprised that is all they do? I am pretty sure their work extends to making sure Agile is being done properly and measuring performance using burndown charts…. but anyway that alone is an important job and without it you can’t do your job and sign off the project!

      I once worked with a tech lead when I was a developer, that was extremely good technically but was a terrible manager. He had the following problems:

      – Did not know how to motivate his team, and get the best out of them.
      – Did not know how to delegate work properly, I guess sure if he learned agile he could do this better. He didn’t work in an agile way.
      – Was terrible at resolving impediments. If there were project delays, grievances, his approach was to blame the developers.

      Project management is not technical at ALL, but the hardest part of it is keeping communication lines open between different teams, and getting them work together to deliver a project. Only because you are extremely good technically, does not mean that you can do that well, in effect improving the processes of the operational side of the organisation.

    2. A

      You sound absolutely horrendous to work with and arguably the very reason as to why PMs are scrum masters are valuable.. You do realize that agile has estimation as a core element right? Jesus… Take a vacation

  28. bob

    Project management is entirely technical in the construction low voltage systems wiring world which is the physical layer for all to do their job in this discussion. The sooner this community realizes this the more open they will be to technical project management. The product development community would serve themselves well to train skilled technical developer personnel that are not PMs to be PMs within the their specific product speciality, specifically on the soft skills of PM. 100% of developers are to technical and have 0 business acumen and management skills. They are continuously blowing up there own project budgets and can’t even see it.

    1. SS

      @Bob You have technical project managers, they are called ‘tech leads’, and are the go to person for all technical questions. Very often they manage their development team, but beyond that have very little influence over other resources in the project lifecycle, BAs, designers etc leading to bottlenecks.

      A project manager is a facilitator. The PM cares about improving the delivery ‘process’ for all teams/resources in the project lifecycle, so that bottlenecks are minimised and work is delivered smoothly.

      Once again, does not require technical skills, but understanding and knowing how to integrate project management frameworks (Agile, Prince 2, Waterfall etc) in a delivery cycle properly and knowing for what type of projects to use each framework!

      A good PM is somebody who has strong interpersonal skills, many technical people are good technically, but find it hard to identify why a process is failing. More often than not they assume it is because of something technical. From experience, the reason why a project management process fails is not because a developer is incompetent, but because there are bottlenecks in the lifecycle – a resource is taking longer than expected; team members having grievances (personal or professional) or misunderstandings about how the work needs to be delivered leading to the developer to implement the requirement not exactly how the client wants it and so on.

      Hence, I have worked under tech leads as a developers who fit this category, and were terrible to work under.

    2. Adrian83


      From my own experience I have learned that software development and software project management have become different fields.

      The software project managers care very little about software development while the software developers care very little about project management. The interaction between PMs and developers/technical experts is relatively limited.

      From what I’ve seen PMs:
      – make request to functional managers for people to be assigned to projects; who really gets assigned is not decided by the PM but by the functional manager;
      – create and update the project plan; all the information from the plan is not made up by the PM but instead it is being provided by the project stakeholders including by the developers (or their technical leads);
      – ensure the team is working on the things that are in the project scope so all that is being worked on will eventually get paid;
      – facilitate communication between all the project stakeholders;
      – make estimates about the project budget;
      – report the status of the project to all stakeholders;
      – resolve non-technical issue that may arise during the project execution
      – do other things related to the project but not directly related to the actual development process.

      All the PMs who I have worked with were not involved at all the in technical aspects of the work preformed and were completely excluded from the decision process taken by the team. On technical issues they had absolutely no authority over the project team. The project team members were not even reporting to the PM.

      Many experienced developers would simply refuse to become PMs because they would completely loose contact with the type of work that they like. For many developers the PM work may seem very boring and something that they would not want to do. Many developers may also lack the soft skills needed for such a job.

      Developers who want to become managers will seek the line/functional management track which is different than project management.

      Usually poor developers would be more willing to be trained as project managers since they would not be able to progress too much in a technical position.

      Experienced developers would be tempted to move to project management if this role is combined with that of the technical leader. In some companies this seems to be the case so all PMs are actually experienced developers. I have never worked in such a company.

      1. SS


        I think that the problem with a lot of developers on here, is this whole idea that the only resources needed to deliver an IT project are technical folk, and somehow they are superior to non technical people in the digital world. It’s that level of narrow mindedness which is why a lot are not any good at it. They do not have the interpersonal skills to do it.

        Non technical PMs may not be as technical but they will probably know much more about the business domain as part of their role than the average developer, which translates into creating roadmaps that stakeholders can understand, documenting risks, and working with cross functional teams that comprise of not only developers but designers, QA, business analysts etc. In other words, getting everybody to work together, not just one subset (the engineering team) to help the business meet their objectives.

        Technical PMs on the other hand just care about technology, and how to get it to work. It’s important for everyone reading the comments section to be aware of the distinction between the two. In a well run business non technical and technical people work together. It’s not one or the other.

        1. Adrian83

          No, no, no. I didn’t say that developers consider themselves superior to non-technical IT people. I only said that many experienced developers would not trade their job for a project manager position that involves no or very little technical involvement.

          The fact that you don’t like to do a job and consider it boring does not automatically mean that you consider that job to be inferior as well ( compared to yours at least).

          Many senior developers have a passion for their work. If they were to become PMs they may not be doing the work for which they have a passion. Well they could still write code at home but it is not the same thing.

          I am sure that many developers respect the work that the non-technical IT professionals are doing but they would not like to do it themselves.

          Now regarding the title of technical project manager I am not sure if this is appropriate for a technical lead. Technical leads usually have very little to do with project management, they don’t manage the project or a part of it they just manage (from a technical point of view) a group of people, usually from their line of work, that are involved in an activity such as in a project.

          Technical leads can also manage people that are performing work outside a project. For instance a technical lead could be in charge of a group of developers responsible for maintaining a software product. Since this technical lead would not work on a project he couldn’t be called technical project manager. I had this role during my career. :)

          1. SS

            Looks like we are finally on the same page, after 30 posts going back and forth.

            Let’s put this argument to bed. To summarise:

            – Tech leads manage only a subset of the project, other developers
            – They do not care about the workflow between other departments to ensure a complex product is delivered on time, or helping businesses define their overall digital strategy. All they are concerned about is the technical team, and what is needed technically to help a business meet their commercial objectives. The project manager does the former.

            So they need each other. Discussion ended.

          2. B

            You guys could never build a construction project.

          3. Adrian83


            Yes they need each other, that’s for sure. However in some development projects, usually less complex ones, the company hires no project managers or non-technical staff but only developers or other technical experts.

            In the above cases the developers have do to everything including managing the operational aspects of a project. Some of them many not be happy with this arrangement but they have no choice.

            On the former project I worked on there was no project manager but only technical experts. The customer on-site technical consultant was dealing with project management issues as well besides his technical duties. He was some sort of jack of all trades: business analyst, solution architect, project manager, developer, he was doing all these things. :)

            From my experience I have learned that there is very little similarity between the work of a “pure” (non-technical) project manager and a “pure” (technical only) technical lead.

            The pure PM and the pure TL care about completely different things and depending on the organizational structure sometimes they don’t even interact at all during the project.

            For instance a few years ago I worked as a technical consultant for a very large company and I delivered (from a purely technical point a view) a project to a department. I saw the PM only once and only to say hi and nothing more, all the communication was done through the functional manager who was responsible for the purely technical aspects of the project. The functional manager was higher in the company hierarchy than the PM who was just an ordinary employee with no direct reports.

          4. SS


            Yes, if the project is simple then there is no need for a non technical PM. By simple, I am assuming that the project has been fully scoped and you know exactly what needs to be delivered right down to how the User interface looks.

            The commercial projects I’ve managed are not that simple, and during the project scoping phase a lot of discovery meetings are set up with the client, where the requirements need to first be established. If done properly, the developer does not need to get involved until the user interface and experience has been established by working with a designer or BA, at which point their role in the scoping phase is to just give technical estimates.

            …can you see where I am going with this? Where the PM role adds value, is ensuring that the communication between the client, BA/designer and technical team is fluid. A good one is involved in every stage of the process and acts like a filter blocking the shit hitting the technical and non technical teams from the client, upper management so that they can concentrate doing what they do best. In your case writing code. This can become quite hectic when you have more than one project on the go running in parrallel.

            I have also found where a PM adds value is defiantly if you are managing a long term business critical product which I am doing right now. A lot of the skills I am using right now is not technical at all, but based around helping my stakeholder understand and define the long term digital strategy of the product. That means I have to understand the product from a non-technical point of view, helping him identify what features to add into the product which gives the biggest business value…Yes, that means I have to produce a quarterly product roadmap, log all risks (operational and product based) in a RAID report, make sure the budget is being spent correctly, track deliverables and be dragged into tonnes of meetings with my stakeholder.

            Can a developer do this, yes they can, but most are not interested and want to just write code and are not necessarily business minded.

            It comes back to my earlier point Adrien, you seem to think like many other developers complaining about PMs that all that is needed to deliver a project is technical skills totally ignoring all of the other skills/people that are needed to successfully deliver one. That is the downfall of many technical people and why they do not make good managers since they don’t understand the bigger picture beyond the tech.

  29. SS


    Being a jack of all trades is not the answer either.

    I bet your friend who was one was a jack of all trades, master of none and the quality of work would get killed by someone who is just a UI/UX designer, Business analyst, PM etc in the same way a full stack developer will get killed by a pure front end or back end developer.

  30. Ravi

    Thanks for the nice words about project manager. And you are article is really inspiring.
    Yes. it is sure not the documentation work. He need to put his complete mind in resolving lot of different types of issues as his day to day activities.
    And It is not at all easy to work as a project manager. But working on challenges are always interesting.

  31. Arrhogahnt

    Making twice as much as any ‘engineer’ (I came up through the ranks as one) makes the PM spot so sweet as green or stuck engineers flail about trying to find self-importance in the world. My check shows me respect.

  32. Mongoose

    I just stumbled onto this article, and managed to get through some of the comments from SS, JK, and Adrian83. I will offer my 2 cents as well.

    I am an IT Project Manager, but I started off on the technical side, Cisco Networking. The article is about “Why Project Managers get no respect”. One of the key points made by the author is that the “Job Title”, Project Manager, is abstract and does not convey much about what one does. According to the author, it sounds like title inflation. He also points out that some Project Managers, per their actions, tend to confirm the stereotype. I agree with the article. The author is not saying that Project Management is a useless, rather that the title is abstract and does not say much to relate to the “real work”. In fact the author highlights numerous achievements in history, that were project managed. The only difference is that the Project Managers had other titles. From the discussion, I agree with most of the things SS said. I do not agree that he said the article was unfair. JK and Adrian83 are quite obviously developers, so I am not surprise. As SS pointed out, those guys do not even understand the role, so it will be useless explaining it to them. The Project Manager is not there to write code, make all the technical decisions, or know everything. Developers, and lot of technical folks do not have what it takes to be a Project Manager even if their life depended on it. They often lack the ability to see strategically, hence the sentiment. In my years of experience, it is the developer/technical guys that will vehemently disagree with someone that says that they lack vision, strategic thinking, and leadership skills. I have yet to find a developer/techie with those skills. The ironic thing is that it is the developers, more than anyone else on an IT Project, that need the Project Manager, but it is the developers that least think they need the Project Manager. Judging from they response here, another weakness of developers is clearly visible here. They do not do well with reading – heck they do not like it. Every role on the IT Project is essential. Good developers are tacticians who see details, but often that is all they can see. Great Project Managers must be able to see strategically, and operationally. Great Business Analysts must see it all – Strategically, Operationally, and Tactically. In fact, the key roll on an IT Project, in my view, is a GREAT Business Analyst. None of the roles are useless. They all have their value. A good saying that I came across is that “You cannot make a great product with 2 developers in the room.” That is VERY True!

    1. SS

      Joined a very large company as a new project manager, was chucked into a hardcore dev ops project:

      – There was no documentation
      – Developers were essentially running the project
      – They were not listening to my suggestions, and carried the mindset all that you need to deliver projects is technical skills and that is it. They felt like Adrian83 was going bang on about that PMs are an unnecessary overhead.

      Outcome of project above:

      – No strategic project plan = endless scope creep, technical and non technical from change requests or understanding properly how to start and finish the project.
      – No strategic project plan = delays from not factoring in annual leave etc delays
      – When resources were reallocated onto the project, often they were confused about what exactly to do.
      – Team became disjointed, all the devs were working individually not as a team. Issues caused by dependencies arose. Some devs were coasting it.
      – Devs did not have time to dev and attend meetings to inform key stakeholders of project status, causing further delays.
      – Delays communicating with designers, other non related technical teams in the project lifecycle

      …in short an ABSOLUTE disaster.

      I have since introduced

      – comprehensive documentation
      – comprehensive planning
      – I do a lot of stakeholder management, not make technical decisions, tech lead does that and I negotiate on his behalf with stakeholders often successfully.

      This is why project managers are hired, they are there to keep things organised and help the team think strategically when delivering a project, not code. One management skill that is extremely hard to do is team building, getting people from cross functional disciplines to work together efficiently.

      To conclude, Project managers are the gel that keeps people together, so that in this case devs can focus on what they do best, CODE.

  33. darkcg

    You (the engineer) do the hard work and put talent in the work. A pat on your shoulder and the PM gets promoted with a raise. It’s not you that are brilliant in what you do. It’s the PM that’s capable of “empowering” people.

    1. Scott Berkun

      The problem in this case has nothing to do with the people or the jobs they have – if whoever is giving out raises doesn’t understand the contributions everyone makes (or doesn’t) then they are the problem.

      Engineering is hard. Managing a room full of engineers to collaborate and make something good is hard.

      1. Adrian83

        The problem is that project managers don’t actually manage engineers. They like to think it this way but 99% of the time in their relation with the engineers they just ask questions, usually about the status of the work being done.

        Managing means taking decisions that others must follow. I have never seen a PM to take decisions that the team members must follow.

        Managing at low level requires taking decisions that are technical in nature. Because of this, engineers are not being managed by project managers but by engineering managers who are themselves engineers and by senior engineers who work as technical leads in different activities.

        If you fire the project manager the engineers can still make something good by themselves, fire the engineers and you can’t do anything just with the PMs.

        I am not saying that PMs are useless, on the contrary they are valuable to the business in most cases, but it is not their job to manage engineers or their work, they just manage the project at the operational level.

        1. Aa

          Adrian, only because engineers can build a product does not mean that they can run a project. I have worked in big and small organizations as a PM, the problems are the following:

          – poor project planning
          – poor communication
          – confusion

          Leading to:

          – delays
          – project going over budget
          – angry stakeholders

          This is where a project manager is useful, they effectively act as a buffer between the engineering team and other parts of an organization, and are often co-ordinating activities between multiple departments by filtering out the shit, unlike a tech lead who just cares about the technical implementation. A good tech lead will be working closely with the project manager to devise realistic project plans.

  34. SS

    Managing a new project mid way through in a large corporate environment. For devs on here calling PMs useless, prior to arriving on the project the following was happening:

    – tech lead not bothering to do ANY project planning leading to confused stakeholders over the status of the project

    – tech lead borrowing resources from other projects without notifying other project managers putting his and their project at risk

    – tech lead not defining the scope, not creating jira tickets, and not updating jira tickets

    Hold and below the project is late.

    Adrien you are right, to be PM does not require as much technical skill, but clearly they needed since I am finding their job is effectively to help people work together as a team and communicate. Otherwise the project ends up going into disarray.

    1. JAN

      I am a project manager, and what project managers do best for those who are purely non technical is notify the stakeholders that the project will be late because of x,y,z. the stake holders then decide between late or reduced scope. Could the engineer have told the stakeholders, sure, and I have seen them do it. At the end of the day, if the PM runs a project in which they do not control the resources, they are project coordinators, not managers, as they make no MAJOR decisions. Sure they can teambuild, ask how people feel, arrange meetings, but that is not making decisions. As such they should be paid accordingly, including myself. Now those people that can convince the customer that what we are delivering is in their best interest because we cannot deliver the contracted scope in the contracted time, those people should be in sales, but it is often the technical leads who do this very important piece. To all the PMs, look back on your projects, how many items were left open simply because the project had ended or the money was out. That is not a successful project, that is a PM patting themselves on the back for not delivering all of the contracted scope in the contracted time. Does your software have bugs that you didnt fix? documentation errors? customer has their internal people filling in the blanks you didnt do? Don’t call that a success, call that the degeneration of commitment to deliver on 100% of what you sold them. But I love the PMS who criticize the engineers for “poor planning”, when all they have done is kept their stakeholders up to date on their own inability to deliver 100%, and then called it a success. It’s like fake news.

      1. SS

        Negotiating scope/managing expectations is a skill in itself. What do you do if the stakeholder is stubborn with timeframes? Right, there you go.

        Where I am working I am involved in major decisions:

        – I can decide which devs I want on the project by talking to senior management
        – I plan the project, that means selecting the right methodology for the project, Scrum, Kanban, Waterfall etc and do the necessary documentation/set up etc
        – If i am under resourced again I am involved in resource planning

        The above has a direct impact of how much of the scope can be completed. A really good PM will plan it in such a way where there is enough buffer in timeframes to deliver what is needed. They will also have processes in place to adapt with change. If there are issues, which always happens, again a good PM will have good mitigation plans in place. If you have nobody doing this, it’s simply chaos as I have just found upon joining. Nobody will know what is going on.

        1. SS

          To add working with stakeholders to prioritise requirements is crucial for good delivery and a skill. Lets assume you can’t deliver a 100% of scope, the key is to help them identify what is extremely important and get the resources to focus on that. A lot of stakeholders will want everything and are bad at it.

          1. JAN

            stakeholders want everything because that is what they contracted us to deliver. stakeholders shoudnt have to balance scope vs time. imagine if your house contractor said it was going to take a month longer, and will be over budget and then started to ask if you can switch out hardwood for lino.

            You would say to him, it is fixed price, fixed scope and you advertised 1 year, please live up to your commitments.

            ITs like we have set expectations that we will never deliver on time on budget AND the original scope

            Negoitiating with stakeholders I find is a simple exercise. Get all the estimates from the engineers, put out the available options based on the dependencies(provided by the engineers) and then ask the stakeholders what they really need.

            IT is more math in my opinion than negoitiation. And I say this because if the stakeholders want to do something within the budget that you cannot do, you dont take money out of your own pocket to hire more people to make it happen.

            And that is the difference between the commitment of the house contractor and the PM. The contractor is obligated to deliver, PMs are obligated to bring things up to the stakeholders to make decisions. And that is why if you ask the house contractor how he did on your house he will say, I lost money, but my customer is happy, and I value that because he is my reference for the next customer. The PM and all the stakeholders do a nice dance at the end of the project and congratulate themselves on being on budget, and how everyone is happy (dont talk about schedule or reduced scope). So when you say you need a PM to plan and the engineers dont plan, why exactly do PMS think they are good at planning when PMS cant deliver the contracted scope in the contracted time for the contracted budget? I’ll answer that for you, because they put the plan on paper. Just because it is in paper doesnt make it good planning.And the minute you adjust the plan, I would ask isnt that bad planning, you just changed your plan? how is this different from the engineers who change the plan as they go? I’ll answer that as well, nothing except PMs put it into the plan and take it to the stakeholders, or if they have budget, go get more resources, if they are available. My point is, it is a simple process.
            1. Ask for status updates from engineers
            2. If not on track, see if more resources available(if you have budget). If you dont have budget, go see stakeholders and tell them it will be late or ask to reduce scope
            3. document stakeholder decision and do what they allow

            repeat steps 1 through 3 every week

          2. SS

            Jan, if project management was that simple, why do companies continuously hire project managers and pay good money for it??? Clearly A LOT of companies see the value of hiring PMs to help keep their projects on track, which is why I find this whole discussion ridiculous.

            Management is an extremely stressful job, especially when projects fall behind schedule and the situation needs to be mitigated or when outside factors are trying to derail your project – last minute change requests, resources being pulled etc. For example, I have a constant battle with senior management to protect my resources at all costs to get work delivered.

            As for stakeholder management, there is much more to it then getting estimates from devs, one of the challenges I have found time and time again is where their estimations are wrong!!!!! A skilled project manager will know this and create realistic plans with enough buffer in so that they can absorb inaccurate estimations and unforeseen issues. To do this, you need to think laterally and strategically i.e. trying to identify the worst case scienario.

            Furthermore, helping stakeholders define their project scope is HARD since many do not know what they want. A skilled PM will help manage stakeholder expectations by using techniques such as MoSCoW to help them define the project scope.

            Finally, and I will say this again, team building is crucial to delivering a project on time. I have worked with developers who were total primadonnas, act as if they know it all and that has created serious project risks not only for me but their colleagues when there is dependency from them carrying the mind set ‘I know best, and it will be done when it is done’.

            If you think management is simple, and are struggling to deliver work in a timely manner, I am questioning your management skills and if you are any good.

          3. JAN

            @SS I’m not debating that it is stressful. It is, because things get behind, and you are absolutely correct on the estimates. They are not right, but let me ask you, how do you know how much they are off by? and if the PM beside you was running the project would he say they are off by the same amount? would they even be close to the same? I doubt it. What does this tell you about what you are doing? To me if you want to be accurate it means you are using your experience in knowing the team, the customer, the product, the delivery mechanism, your own process, the customer expected quality. Countless devlopers do not include QA, but instead of you padding the estimates, why not get the developers to provide the better estimate. Because you know what else happens, finance is padding the budget because they think you will need more. Everyone is padding everyone else. Why not have one version of the truth, fully documented? I’ll answer that, becasue everyone thinks they need to add value, where what they should be doing is documenting the process, the inputs, ascertaining basis for risk, etc. one version of the truth.

            And so you know, one of my projects won project of the year a couple years ago, for the 400 miillion dollar company I work for. Why? improved margin,and customer satisfaction. Was it on time, no. So am I good at what I do, yes. But do I think I am overpaid for what I do, yes. You do bring up a good point about why do companies pay for PMs. I think this goes back to my earlier post. People dont come through on their commitments and are not held accountable so they need someone to essentially continually tell them what is wrong and possbible ways to fix it. Be the messenger with bad news, confidently. Not an easy job in that context, I just dont think it is complicated. Stressful yes, because not everything is in your control

            I think I started to realize I the PM role was perhaps a little to overcomlicated when I was doing the PMP prep course awhile back. One of the questions was along the lines of. You are making a presentation to stakeholders which will result in a major decision. Ten minutes before the meeting your team lead tells you one of the numbers is wrong. you
            A) change the presentation
            B)reschedule the meeting
            C) give the presentation and tell the stakeholders the error
            Cant remember what D was.

            anyway I think I indicated A.

            I was told this is wrong, it should be B, because the the stakeholders time is important and you shouldnt be giving them wrong information. I then asked, what if the question was changed to 1 hour before the meeting,5 hours? 1 day? At this point the instructor told me that there wouldnt be a question with other times. I said why not. And then she could not answer. I said let me tell you why not. Because no PM would make a decision on the information provided in the question. The first thing the PM would do is determine the IMPACT of the wrong number.

            But there a significant number of PMI questions are this type of question, where no one would actually do any of the answers without some more information. So why do they put these types of questions in? IMHO to ensure people do not get 100%. In other words, they are trying to make it more difficult that what they have written down on paper. It is PMI legitimizing itself by making the test hard

          4. SS


            “To me if you want to be accurate it means you are using your experience in knowing the team, the customer, the product, the delivery mechanism, your own process, the customer expected quality. ”

            “Countless developers do not include QA, but instead of you padding the estimates, why not get the developers to provide the better estimate. ”

            This is my point, delivering projects well is not a skill but an art. Yes, being a developer is technically harder and nobody will argue with this, but not everyone has the analytical, organisational, leadership skills to be a good manager. When I was a developer, I once worked with a technical lead who managed a product, he was technically good, but had a hard time prioritising work, controlling the scope, and motivating the team so that they worked efficiently. Whenever there were conflicts within the team, he was not diplomatic enough to handle the situation properly. If the conflict involved him and a member of the team, I remember his approach would be to take that person straight to a disciplinary hearing (worsening the situation) instead of looking at the existing delivery process, understanding how that conflict came about in an attempt to try and avoid it in future.

            To build on another point you have made, a good project manager is detail oriented, devs do not have to and are expected not to know about of the whole project lifecycle, all they care about is can x requirement be technically done or not. This goes back to my point of why project managers are paid well given it is their plan based on the overall picture that the project team is following. If the PM gets it wrong, they are held accountable not the developers.

            When I have worked on projects, there are multiple teams working on large scale projects, not just developers, because of that there are dependencies meaning that this is a team effort. Somebody has to manage that process well building on the point above.

            You also keep coming back to the argument of project managers not delivering what was originally promised, therefore not doing what they are there for. At the end of the day the scope is defined by the stakeholder, if you are able to descope the project – which requires negotiation skills – then you are doing your job and I don’t know why you are complaining.

            To conclude, the stress alone justifies why it should be well paid. The reason why it is stressful is because the role comes with a lot of responsibilities. If the PM is in control of budget and resources, it is their decision making in the end that will have a direct impact on whether the company makes money or not.

          5. JAN

            @SS, I’ll admit I am lucky to work with great professionals, with no real HR issues. No one has ever tried to sabotage my projects So you have a good point there, but that is more HR management than something unique to project management(still part of PMing, yes). I’d ask you though, how is this any different from the crew leader at McDonalds. He/She needs those same skills

            So I think we then agree that simply having a PM does not mean the project will be on budget, will deliver the original scope, or be on schedule. So for all those that blame the engineers for not planning, please stop doing so. At the end of the day it is the engineers that tell you the estimates and the dependencies, which is essentially the plan. I once was given a piece of a larger project to manage. Very simple. The main project manager kept asking me for updates. I said to him, why dont I just update your schedule once a week and then you can stop asking, and I will make sure I tell you if resources dont show up on time, so you can escalate. But he didnt want me updating his schedule. So I would copy out his schedule, update it and then send it back. Useless time, and that is what I find a lot of project managers spend time doing, moving paper. I also once came across the pure textbook project manager on the customer’s side (we were delivering to their specification). This is all he ever did every week and it turned out great for him
            1. Ask for status updates from his engineers and us
            2. If not on track, get everyone in a room to determine why not.
            Once a reason is ascertained, then ask who can fix it. Then escalate for this persons time. Also ask why no one told him about this dependency
            If the problem is with the Vendor(us) ask if we can recover the time, if not escalate it with our management. If it is debated as to if we should do the work or them, we both search through the table of compliance. Then we argue if line item x in the TOC actually means what needs to happen now to fix the problem. Or we get blamed for not telling them every single detail. If no agreement on cost or scope, escalate
            3. update schedule

            repeat steps 1 through 3 every week

            It’s just not that hard because the PM never has an answer to a problem. It is just the same methodology over and over again. Get more resources, escalate. Keep track of money do your forecast and tell people when you are going to run out and perhaps not be able to deliver on scope. Notify stakeholders

            I should write a song. Maybe I’m just bored because I have been doing it for ten years.

            But I do agree it is stressfull, or used to be for me. It is less so now since we moved to a model of not controlling the resources. I just tell upper management if I dont get person x by date y, schedule will slip. And if person x wasnt in my original request, I just state the documentation in order for me to solve my problem was insufficient for the other resources on the team to fix the problem, or this needs to be done because of product defect Z(we own the product we deliver), please have the product group fix this problem and then I dont need person X. This is my point, the reason things are late is rarely because the PM did or didnt do something something.I’ve never heard a PM say, it is late because I didnt do xyz. Projects are late because of the technical difficulties or a problem out of the PMs control (once again because he controls very little) He or she just follows the original three steps I posted. Back to my example, …upper management escalates my problem to the product group (if it is a product issue), and they then ask, which product defect would you like us to fix, because we are already fixing these escalated ones over here. Around and around it goes. At the end of the day it is about escalation once the planned resources cannot make the plan, scope, budget. And in my opinion, this is not difficult, stressful no doubt about it, but not all that difficult. And it is why I see it more as project administration, than management

          6. SS


            “@SS, I’ll admit I am lucky to work with great professionals, with no real HR issues. No one has ever tried to sabotage my projects So you have a good point there, but that is more HR management than something unique to project management(still part of PMing, yes). I’d ask you though, how is this any different from the crew leader at McDonalds. He/She needs those same skills”

            You can’t compare both, digital management requires someone to have some technical knowledge to be good at it. Of course there are PMs who don’t, but it goes against them with devs putting wool over their eyes. I don’t code anymore, but the technical grounding gets me out of jams.

            People management is hard, yes indeed you are lucky that you have never worked with primadonnas, I have, do you know how stressful it is when you are working with egotistical stubborn devs who do not listen to you and threatening to derail your project?

            Descoping projects can be tricky too, what if the stakeholder is stubborn??

            Yes, technically PM is not as hard as coding but at the same time it’s a hard job with a lot of pressure and stress when things are not going well. When a business hires a PM, essentially they are expecting them to deliver the project in a timely manner within budget. Good PMs can. People who are not very good at it will not causing the budget to go out of whack.

          7. Adrian83


            “People management is hard, yes indeed you are lucky that you have never worked with primadonnas, I have, do you know how stressful it is when you are working with egotistical stubborn devs who do not listen to you and threatening to derail your project?”

            Project managers are not supposed to do people management, as a general rule this is not their duty and most of them don’t do it. People management is the responsibility of the line managers to which the employees report to.

            If the project manager thinks that there are issues with some employees working on the projects they manage all they have to do is to escalate the issues to the real people managers.

            Project managers don’t bring value to companies by taking decisions but by identifying what decisions have to be taken and finding the appropriate people that can take those decisions.

            For instance technical decisions on a project are not taken by the PMs but by the technical experts, PMs however have to find out what technical decisions have to be taken and ask the technical experts to take them. It is not their job to question those decisions but they have to understand them and see how they fit into the project and perhaps discuss them with the project sponsor and/or management so they can decide too.

            “When a business hires a PM, essentially they are expecting them to deliver the project in a timely manner within budget. Good PMs can. People who are not very good at it will not causing the budget to go out of whack.”

            Perhaps some companies actually expect this from their PMs, but in most cases the PMs don’t have the ability to deliver the project on time and on budget. That’s because may things are beyond their control. At most the PMs can help the company deliver on time increasing the chances for success but by no means good PMs can deliver on time and on budget just by using their project management expertise.

            Good project management helps a lot but it does not guarantee the success. We must not forget that it is the team that actually delivers the project and not the PM. The skills of the team members are equally important if not more important than project management. Not to mention other factors that are beyond the control of both the team and the project managers.

            Even if you have the best PM in the world and the best project team your project can still fail to deliver or it could end up delivering things that are not needed if the organization’s management does not do its job well.

          8. SS


            “Project managers are not supposed to do people management, as a general rule this is not their duty and most of them don’t do it. People management is the responsibility of the line managers to which the employees report to.”

            Wrong, wrong, wrong, wrong…well depends where you are working.

            Where I am currently working, a well known billion pound company, I am actively doing this as well as identifying issues and risks to senior management. That part is true in your assumption.

            Yes, the developers I am managing direct line lead is the technical lead, but his role is strictly down to making/signing off technical decisions and is not involved in managing his team during the life cycle to delivery. Effectively the way it works is where he lends me his resources and I manage them directly. In other words, I create the delivery plan, and they all follow it. Easier said then done when you have egos in the team. Also the fact that they are all following my delivery plan means that I am accountable if the project fails. This is why the job is hard.

            “If the project manager thinks that there are issues with some employees working on the projects they manage all they have to do is to escalate the issues to the real people managers.”

            Ironically, we have an issue with the technical lead who is generally unreliable.

            How do you mitigate that situation??? There are 2 approaches, escalate immediately to senior management, or deal with the person directly and try to get them back on track…This is the headache I have to deal with on a day in and day out basis.

            “Project managers don’t bring value to companies by taking decisions but by identifying what decisions have to be taken and finding the appropriate people that can take those decisions.”

            Projects I am delivering follow my strategic delivery plan, which is signed off by head of delivery and product owners.
            Yes, I have to create a gantt chart.
            Yes, I have to set up the meetings and make sure everyone attends dealing with impediments as they arise to keep the project on track.
            Yes, I have to deal with the headaches that comes with managing a cross functional teams. People complaining, going on annual leave, being sick etc.

            “For instance technical decisions on a project are not taken by the PMs but by the technical experts, PMs however have to find out what technical decisions have to be taken and ask the technical experts to take them. It is not their job to question those decisions but they have to understand them and see how they fit into the project and perhaps discuss them with the project sponsor and/or management so they can decide too.”

            LOL this is exactly why developers don’t make good PMs, they are not lateral enough in their thinking. The technical side of the project is one important part of delivery, what about requirement gathering, documentation, planning, visual designs, getting resources available to you to work on the project?

            Indeed, I am not involved in technical decision making, techies are, but again, they are following my delivery plan and timeframes. From my side, I have to make sure that you have all the information available to make the correct tech decisions.

            “Perhaps some companies actually expect this from their PMs, but in most cases the PMs don’t have the ability to deliver the project on time and on budget. That’s because may things are beyond their control. At most the PMs can help the company deliver on time increasing the chances for success but by no means good PMs can deliver on time and on budget just by using their project management expertise.”

            As much as it is about delivering work on time and within budget, it is about helping the business identify and deliver value. That is stakeholder management. Also, I have in the past delivered projects on time, not EVERY project is going to be delayed, it happens of course, but it probably would be less of a delay if someone with no PM experience was delayed.

            “Good project management helps a lot but it does not guarantee the success. We must not forget that it is the team that actually delivers the project and not the PM. The skills of the team members are equally important if not more important than project management. Not to mention other factors that are beyond the control of both the team and the project managers.”

            A good project manager will be skilful enough to facilitate the process, and very often it is the their plan the team is following to get to the end goal, delivery.

            Sports is a good example, every sports team has a manager, they are not actually on the court playing the game, the players are, but they are giving instructions strategising the game with the team. Without a manager, the team will be disorganised and may not work together to win the game. That’s the value a good PM brings, they keep projects in control and get otherwise individualistic egotistical people to work together to hit a common goal. Team building is hard, you see it all the time in sports, teams with superstars underachieving in contrast to teams that do not have them.

  35. Patricia Young

    Results don’t drop from the sky. It requires planning. All my projects were successful in delivering the required quality results within the time frame.

    1. JAN

      right, you must have projects with no people, no customers, unlimited budget, and no fixed timelines

      i.e. your project must be you living in the woods, and your project is to find a tree every day maybe every other. And every day you find one. Hopefully there is no fire

  36. Sasha7

    Just came across this blog because I am little disillusioned with project managers. I was previously project manager with technical and business background working my way up to PM. In my current and past company, I am seeing/saw an increasing trend to promote executive assistants, PAs into project managers and scrum masters. This gives new meaning of glorified secretaries. Wonder what people think about this? Seems like increasingly companies see PMs as co-ordinating role which anyone can just do. Don’t worry you don’t understand the technical details of the project, what you are delivering and whether stakeholders are telling you the truth…seems like just as long as you can co-ordinate and take minutes you are qualified for the role. Those PM certifications are so easy to get, spend your dollars and a few days and you are all set to be a PM. Sadly I see a demise of the project manager.

    1. Adrian83

      Yes it appears that many if not most of the organizations today expect their PMs to be just some sort of coordinators and facilitators rather than real leaders or real managers.

      In all the large companies on which I have worked PMs were not even real managers but peers to the project team members. It is not uncommon for some project team members to be more senior and better paid than the PM.

      Being a project manager in many companies is just a job like any other job it is not a management position. Most PMs are not higher on the corporate ladder than the team members that are working on the projects that they manage.

      Since the PM is not a higher position obviously a lot of people can be appointed in this position.

      I don’t want to offend you in anyway but since the role of the PM is more about communication, facilitation and soft skills some executive assistants or secretaries can be better suited for the job then some good technical experts. Don’t forget that the PM is not a technical leader.

      A former executive assistant that has become a PM would not be able to take technical decisions on the project but would just facilitate the decision process helping the technical experts to take the best decisions. The technical leader in this situation could focus entirely on the technical issues and don’t be bothered by other things.

      1. SS


        Coordinating work and dealing with people is a skill in itself that not everybody is good at. It is not easy either, especially in highly political corporate environments where you have to deal with many stakeholders and have to protect the team from external interference which often leads to dealing with and resolving conflict. One of the challenges I face daily is with stakeholders trying to overload my technical team with work, a weak project manager will not know how to push back and be walked over. A good one will push back, and in the process gains respect from the technical team. This part of the job is extremely stressful, many difficult conversations take place.

        I have met many technical people who behave as though it is easy to do this (like yourself), they also happen to be the worse managers blinded with arrogance. Yes, they can make *technical decisions*, but they lack the interpersonal skills to build a strong cohesive cross functional team that is optimized successfully. One of the challenges that comes with optimizing teams is trying to get different personalities to work together, improve their ways of working and resolve conflict.

        There is a lot more to the role than delegating work, good project managers shape and change the operating model of the business for the better. To do this, this requires commercial understanding and the ability to use metrics to influence change. I am regularly analyzing the reports in Jira to identify bottlenecks and proposing better ways of working.

        Finally, and this is why your comment is annoying, when things are going wrong it is the PM that turns into the scapegoat, making the role extremely stressful and high pressured. Hence, why PMs are well paid.

        Your post is offensive and you just sound like a typical arrogant technical guy, who thinks that the only skill needed to run a business is being technical ignoring that it’s soft skills which is the key to getting people to work together as a team.

        1. Adrian83


          I just tried to explain to @Sasha7 why secretaries and executive assistants could be good candidates for project management roles.

          I met a former secretary and executive assistant that had become a PM and was managing engineering projects. She was very good at it. Of course she couldn’t manage the engineers ( they had an engineering manager) as she lacked technical knowledge but she was managing the operational aspects of the engineering projects very well.

          In my opinion the biggest strength of a PM is not his ability to plan the work of others (this is something that is not very difficult) but his/her ability to influence people without having authority over them. That’s in my opinion the real hard part of project management.

          A PM needs to get senior managers, customers, functional managers and technical experts to work well together and for this strong communication skills are needed. Secretaries and executive assistants because the nature of their work can develop the required skills for project management better than technical experts.

          The problem is that many people mistake the project manager with a real manager or with a technical lead and have the impression that he/she must take the technical decisions and give directions to the project team members. Normally the PM is not the decision maker on a project but the one that facilitates the decision making process. This happens because in some cases the technical lead or the technical manager also performs the duties of the PM.

          1. SS

            “Secretaries and executive assistants because the nature of their work can develop the required skills for project management better than technical experts.”

            Although an important aspect of the role, there’s more to PMing than organising work. To avoid repeating what I wrote earlier, a good PM in digital tends to have a mixture of technical knowledge, organisational, problem solving skills, and is analytical i.e. using metrics to drive change. Yesterday for example, I was talking to a developer in the project team about a technical process that exports a file in JSON, which in turned helped me understand better what they are doing and how to mitigate a situation enabling me to keep the project on track. Do you think that a secretary could do that?

            You are simplifying the role implying anybody can do it, when there is a lot more to it. I would go onto argue that the best PMs are basically former developers, that have strong interpersonal skills. In my case, the reason why have chosen to be a PM and not tech lead is simply because I find the operational side of the business more interesting.

            Adrian, from reading your comments, what gripes me is how you seem to undermine the difficulty of the role. I actually would argue it is harder than being an engineer given the level of responsibility, pressure from all sides of the business to get work delivered well, consistently. Whereas all a tech lead cares about is making the right technical decisions, and that is it. This is why PMs are well paid, and respected. Good one’s have the power to influence not only people but how the entire business runs.

          2. Bob Figone

            I agree that the barriers to entry in the soft skill professions for PMs is probably less for PMs than for engineers or developers. But those of us skilled PMs in a very small niche of the construction industry, specifically in our specialty of providing network infrastructure for end users, have to build systems for new buildings to provide the information highway and integration to users in every market sector. Some of us have been involved in this work since the days of the main frame and the Bell operating companies. We have had to keep up with the explosive growth and demands of business and government since those days and evolve the technology infrastructure worldwide to meet the ever changing demands of users. We continue to design and install the information highway wiring locally and beyond to include communications wiring, wireless systems, emergency systems, security systems, AV and digital signage systems that average users take for granted. And, unlike other MEP trades in construction we are the subcontractor’s which usually remain onsite at the very end of projects, through client move-in and beyond, supporting them as they acclimate to a new space or building.

            In our world the PM is the technical expert, requiring the overall systems knowledge, solid interpersonal skills to bring disconnected parties together, financial management skills to deal with usually unrealistic budgets, and be able to provide value engineering ideas on the fly to meet changing requirements. Our goal has always been to provide subsystems for networks to support company/user network needs into the future for 10 – 15 years.

          3. Adrian83


            I have been working in IT in technical roles for more that 10 years but so far I have only seen just one PM that had a technical background. Also I have seen that in IT most companies don’t value technical knowledge when they hire PMs. Yes many technical experts may move to project management but in most cases this is not the normal career progression for technical experts. An engineer can progress from an entry level technical position to CEO without being a project manager. The role of the project manager is usually not an intermediate step from engineer to CEO. PMs however can also progress to CEO.

            Project managers in large companies, in IT at least, have a career progression completely different than the technical experts. In some countries (like the UK and Australia) you can start your career as a junior project manager as your first job after you had graduated college.

            I personally believe that PMs should have a good technical background but it appears that in IT most companies don’t think it this way. I believe that for many companies a wedding planner would be a much better choice for an IT project manager role than an IT technical expert. They want someone able to organize things and facilitate the communication between stakeholders rather than someone that can lead a team from a technical point of view.

            These companies probably believe that since they have senior technical experts capable of managing the projects from a technical point of view then there is no point for the PMs to also have technical backgrounds. When both your technical lead and PM are good technical experts you may end with conflicts and since the technical lead is usually not subordinated to the PM this can lead to big problems in your project.

            Could you please explain why so many companies from IT don’t value the technical skills when they hire PMs? I know this is true because I have seen it numerous times. Thanks.

          4. SS

            Yes there are PMs working in digital that are non technical and it makes their job harder. On the same note, there are many that have technical knowledge. I am one, and it helps me immensely when communicating with developers and managing stakeholders by accurately describing issues as they arise. I honestly would be lost if I had no technical knowledge at all. Sure, I’m not CTO/tech lead level in terms of knowledge but I understand the fundamentals.

            Only because you have not met many, does not mean that they do not exist.

          5. SS


            As I said, I simply am not passionate about coding to go down the traditional developer > tech lead > CTO path. It’s boring, that is why I am a PM, since it’s less about choosing the right tech but more about delivery.

      2. SS



        Like other soft skill professions; sales, marketing etc I will agree that the barrier of entry as a PM is easier than being a developer. But like every profession there is a huge difference between those that are good at the role and those that are not. Good PMs also tend to have a technical background (I do) to enable them to communicate better with the technical team.

  37. RadioClash

    1. This is absolutely hilarious!
    2. PMs have always been in high demand across multiple industries with high compensation, investment in training, and career paths to Director or VP positions, so it blows away the silly argument that it’s a role that is undervalued and not respected– this dude didn’t know what he was talking about
    3. It’s not shocking that the harshest critics are overconfident developers. In my experience, it’s these *sshole devs that don’t respect PMs and cause conflict— often intentionally. That being said, it’s a small number of haters compared to the entire cross functional team that highly respect and value PMs: E-staff, QA, Marketing, CS, Tech Pubs, Supply Chain, Legal, Finance, Third Party Partnerships, the cool devs, etc. The best way to navigate these dominant behavior types is to counter their aggression with facts. You’ll often find the brightest devs know nothing about the admin tools (e.g JIRA) or can’t even update a ROI sheet. Thus, that’s usually the point the PM becomes their best friend.
    4. Lastly, the best PMs are great listeners and data gatherers so they have the facts when reporting to the e-staff. They are also great speakers and know how to get right to the point to get to decisions quickly. You know you have a good PM if emails are concise and meetings are shorter/less frequent. Inexperienced PMs make the mistake of scheduling meetings when all they needed to do was talk to a few people offline. Good PMs also shield the teams from bureaucracy and politics they don’t need to be concerned with. Establishing a solid PLM to plan future projects should be lightweight in concept and heavier in resources and time entering definition.

  38. Eddie

    Ever heard an orchestra warming up? That’s essentially what you get with a bunch of experts all doing their own thing in their own way. Of course John Williams can’t play every instrument in the orchestra, nor can he do so as well as each individual – but he knows how to pull it all together so it’s not a big bunch of crap on “launch” day.

    2019 the software industry is still very immature. When software hits launch day with the reliability of a car rolling off the production line, (that industry went through similar growing pains) then there’d be some credence in the objections of coders. Right first time, every time is possible. Until then put it down to lack of vision.

    1. Scott Berkun

      “Ever heard an orchestra warming up? That’s essentially what you get with a bunch of experts all doing their own thing in their own way.”

      I loved this metaphor Eddie. Thanks.

      1. SS

        Since doing a pure Scrum Master role for a couple of years, I can definitely say that teams can work in a self organised way to a certain extent.

        Hence, some degree of Project management is required when team members need ‘reminding’ to do tasks and mitigate risks.

  39. Julian Elsey

    As a Deputy PM I find the distain we are held in very hurtful. A PM never switches off, and our social lives suffer because of this.
    Essentially a project can simply not be delivered without us – end of story.
    Many times I’ve thought about leaving this field due to the constant ridicule I have to endure on a daily basis.

    1. Adrian83

      “Essentially a project can simply not be delivered without us – end of story.”

      I would argue with this statement. I would say that a project can’t be delivered without at least some basic project management principles applied but you can deliver projects even if you have no project management specialists on the project teams.

      Only PMs that have no knowledge about software development or no knowledge about the domain in which the software is being used are ridiculed.

      PMs that are knowledgeable about the things that happen in the project, they don’t have to be experts, are if not respected at least not ridiculed.

      Unfortunately there are many PMs in IT and software development that understand almost nothing from the activities that are being performed on the project, every task for them being just a label in a document or in a project management software. These people get no respect indeed especially when they claim that they are leaders, mentors, etc. They are just purely glorified secretaries.

      Developers only make fun of the PMs that are unable to have a basic pertinent discussion about the work that needs to be performed.

      1. SS

        My opinion has changed since we last spoke. Agree with pretty much everything you say now.

        Projects can be delivered by a team of developers but where a PM adds value is to support them to remove complex blockers (organizational). In a small company org impediments can be resolved without a PM, but enterprise orgs where you have several layers of stakeholders it is much harder – a good PM is skilled enough to be able to facilitate the right discussions and influence change working collaboratively with the team.

        Hence, on that note, a PM should not be expected to be technical, that is a bonus. Commercial awareness is much more important for them.

  40. Wendy T Alphin

    Thank you very much for this presentation. It has brought me much light and provided me with knowledge in PM. I now understand and know the key fundamentals of the project management process.

  41. Zero327

    Some points:

    1. Yes, a group technical experts or developers *CAN* deliver any project left to their own devices. Will it be a quality project, within budget, or within acceptance criteria as determined by the business (operations)? Almost definitely not.

    2. Are PMs needed in small projects? Yes, absolutely. Not to execute, but who do you think is training your business to provide enough descriptive detail that a developer can determine an acceptable solution? Who is reviewing the change request to make sure it’s not trash and worth your development time to begin with? Who is keeping ten more change variants all related to the first request from hitting the developer 2 days apart as not all detail was included in the first draft or approved change request? That useless admin…

    3. The job of a PM isn’t to know every technical detail. Developers, your Vice President DOES NOT CARE WHY a project is behind. They care if it’s on budget, on schedule and if it’s northeast there’s a concrete plan immediately prepared to fix it, NOW! So while you say there’s no method in software development to always know how long something will take, it’s the PM running cover for you with that VP.

    To whoever said they could do the PMs job in addition to their development role, I dare you to walk into your VP’s office with that entitled attitude and tell them you’ve got it handled. Your PM will breathe easier with you on the soup line.

    Good PMs are why the business has to justify cost before something is sent for development. They’re the reason why developers only have to clarify 5 things instead of 100 on every request. PMs know what platforms the company can and can’t afford. And while the developers may know what the *BEST* technical solution is, it’s your PM who knows if your executive is willing to pay for it and the budget condition of the company.

    There are some amazing developers out there. But the unbridled arrogance and hubris of many developers on this blog is obscene.

    CIS and ENG majors are a dime a dozen. Given unlimited resources a trained monkey can deliver a project. But to do it well, quickly and efficiently is why PMs exist. This doesn’t need to be explained to strong high performance developers. So if it had to be explained to you, you’ve got some introspection to do…

    Finally, a PM should absolutely have input into his team’s performance, whether that team is matrixed or direct report. Performance is easy to measure, do they hit reasonable deadlines that they often provided input into setting, and is the quality of their deliverables reliable and typically free from defect? If overly technical, I can always go to their line manager for collaboration.

    But in this blog the developers who say estimates can’t be given, performance measurement by the PM is irrelevant and metrics are just for blame/shaming, these are the developers who want no accountability. Because deadlines missed, deliverables half assed and projects failed, when documented properly, result in turnover of incompetent technical resources, not PMs.

    Think about that the next time a developer, any developer says documentation and approvals are a waste of time.

    1. SS

      All valid points, but software development is moving away from traditional waterfall PM delivery to Agile now, where PMs no longer exist as a role.

      1. Zero327

        Agile is one of several methodologies. It is not a silver bullet and has very specific uses just as waterfall does. The future is a hybrid philosophy that purists advocating for either pure waterfall or agile both miss the train on.

        Project Management as a role is changing. The future of the PM profession includes machine learning, cloud and emerging technologies integrated into administrative tasks and leadership above even those. Read the below article; more likely is exactly what many devs in this blog fear, empowered PMs (good and bad) who are far closer to being decision-making leadership than peers to engineering or developers.

        Technical resources (people for those sensitive to being treated as a number) will can’t oversee their own spend, direction or strategy of the business. They’re stereotypically too insensitive to budget, business and customer for that. Someone must always conduct the train (to turn an agile phrase). THAT is why there will always be PMs. The executives are too busy, and inmates can’t run the prison.


        1. SS

          “Technical resources (people for those sensitive to being treated as a number) will can’t oversee their own spend, direction or strategy of the business. They’re stereotypically too insensitive to budget, business and customer for that.”

          That’s the Product Owner role in an agile environment, not technical development team.

          “Someone must always conduct the train (to turn an agile phrase). THAT is why there will always be PMs. The executives are too busy, and inmates can’t run the prison.”

          Mature agile teams do not need a PM, the whole point of doing agile is to have self organised teams, where a PM will become a bottleneck for that.
          The agile events such as stand ups, retrospectives, planning, refinement are feedback loops to collectively enable the team to manage risk efficiently, where in contrast PMs will own and manage risk using RAID logs.

          Furthermore, good agile team’s have a Scrum Master supporting them, whose role is not to own the process like a PM does, but coaches the team agile and agile best practice to give them the knowledge needed to apply agile practices properly.

          1. Zero327

            Agnostic isn’t wrong. Too many firms are treating Agile like it’s the solution to all development and deployment concerns, it’s not.

            SS, you argue the PO role replaces PM, but they’re not the same. A PO has to be in the trenches with the team by argument of Agile’s methodology. And to Agnostic’s points, Agile teams actively dodge making commitments they can be held too more often than not.

            A PO in my experience is a dumbed down PM role that is told to focus less on the big picture and more on the technicals. This means your PO often doesn’t know the company budget, constraints, cross-functional dependencies your product management team in agile terms) and little accountability to try to.

            You argue a PM isn’t necessary in Agile, I argue that PMs keep resources and the methodology honest and accountable; this is why ultimately Agile WILL FAIL. It has specific uses, but most firms use some adoption of wagile, and even pure Agile has failings that a cash-strapped firm or finicky customer can not afford.

            Agile is not the answer to all ills, it doesn’t replace strong PMs and good project management, and I’ve been at a firm that introduced Agile as an excuse for IT to bypass and eliminate all PMs in the division. I then watched their spend spin out of control, accountability plummet and spent months sitting with executives explaining that developer lip service was precisely why that structure had failed. PMs back in, and suddenly there’s transparency again.

            80/20 rule. At any given time 20% of your devs are doing 80% of the work (it’s a separate conversation that every developer thinks they’re the 20%). This means that 80% waste is present. A PM finds and reduces this imbalance. Left to their own devices, the building on fire, the company one dollar from bankruptcy, a development team on Agile will spend indiscriminately. Because the design of agile and the mindset of its supporters know no other way.

            That’s why when you’re told to adopt Agile, the first thing they say is it doesn’t count unless you buy in unconditionally and fully. The only other methodology in the world that operates that way is organized religion. And it should be examined carefully and with great suspicion as a result.

        2. Agnostic PM

          Ah yes agile, the saviour. Feel free to google “agile” “fixed price” “fixed schedule”.

          What do you find, not a lot, why? Agile makes no commitments, the only commitment they make is to spend the money. Works good for a software shop making a product with no paid for requirements, doesn’t work when there is a real customer who is paying for a set of requirements. I have seen it all too often, deliverable is late, or the deliverable doesn’t have all the features the customer wanted, or the agile guys on purpose make the requirements so vague, so they can weasel out of delivering them. If the customer asks for something such as the name field must have 128 characters, the agile guys reject that requirement as too detailed. In the agile person’s mind, they are allowed to decide how big the name field will be, because they must be smarter than the customer. and when the agile guy decides to split the name field into name1,name2,name3 for some unknown reason and the customer tries to write a report, he then realizes he must concatenate the names together and get pissed off, the agile guy says, oh you didnt tell me that you didnt want to concatenate, can I have more money?

          show me an agile project which came in on the ORIGINAL budget, schedule and feature set and a happy customer

          1. SS

            ‘ show me an agile project which came in on the ORIGINAL budget, schedule and feature set and a happy customer’

            Many waterfall projects get delayed too.

            What’s your point?

            At least agile is a lot more upfront with managing expectations as opposed to over promising and under delivering.

            The whole point of agile software development is to not promise to deliver everything but be value driven, where the backlog is prioritised by value with high value backlog items priority in the timeframe allocated. This ensures that the clients more important requirements get done in the timeframe allocated.

            If the whole scope of work hasn’t been delivered in the timeframe, and the Stakeholder wants additional work delivered then that is a discussion that the business needs to have with them.

            ‘ so they can weasel out of delivering them.’

            ‘Commitment’ is a Scrum value , mature agile teams adhere to delivering their work to meet goals.

            ‘If the customer asks for something such as the name field must have 128 characters, the agile guys reject that requirement as too detailed. ’

            You can have detailed requirements in agile, actually, it is bad practice to prioritise anything in a sprint if the story is not ‘ready’ to be worked on, by that not properly understood by the team before being picked up. As part of that the business requirements is reflective of the clients needs and should be properly understood. This is the point of doing backlog refinement sessions.

            Agile is not the silver bullet, you are right but it is a lot better than the alternatives when done well.

            The reason why many businesses fail to do it properly is because they are poor agile practitioners, that are attracted to agile’s iterative delivery but lack the deep understanding needed to do it properly.

          2. Agnostic PM

            regarding this:
            At least agile is a lot more upfront with managing expectations as opposed to over promising and under delivering.

            Is it managing expectations? or is it setting no expectations?

            I have seen both methods in my organization. all I ever see out of agile is, “we didnt get to it all”. so the PO or Product manager is constantly deferring. My two cents on the problem with agile: They leave the actual work until the end(because they dont want to commit a date until a point in which it is actually almost all done), then they realize they cannot do it all, or they have problems and have to delay. But they will tell you they never committed to begin with so they are not late. We just had a customer come unglued because they dropped scope at the last minute. What was our response, oh dont worry we will get that to you next quarter. IMHO agile is good for a brand new piece of software where customers don’t really know what they want, and want to pay people to create software and continue to refine.

            In our organization the customers have to guess at what might or might not be delivered because there is no commitment. Sure this is refining the backlog for higher priorities, but would you want to live your life like you are in an Emergency Room triage, getting bumped and waiting. The difference in waterfall, is waterfall makes a commitment and adds resources to make the commitment…because it is a commitment. Do they always make it, no, but the PM is there to make sure they at least try and to bring it to management to get more resources. It is a fundamental philosophy difference. Try and deliver what your customer pays for, or “manage your budget to the highest value”. One is commitment focused, the other is budget focused. of course if you do waterfall poorly, you will go broke. If you do agile poorly, you lose your customers and then you go broke

          3. SS

            A lot of orgs are not doing agile properly and it sounds like yours is no different.

            It’s hard to do it properly.

            “ In our organization the customers have to guess at what might or might not be delivered because there is no commitment”

            One of the scrum values is ‘commitment’, where the expectation is for the team to deliver what they say they are going to deliver to meet a sprint goal.

            If that is not happening at your org, the issue is a lot deeper and indicates a lack of understanding of how to apply agile principles and concepts properly.

            Incidentally, with the above in mind, Risk management in agile is better than waterfall where if the team are consistently not meeting their goals that in itself should be a massive red flag. Unlike a waterfall environment there is a higher level of transparency, where this is seen sooner.

            In a waterfall environment too because there is a single person owning the process – a project manager that can lead to a risk in itself, the whole process breaking down if they are not around.

          4. Agnostic PM

            I think you are correct in the PM not knowing the risk, and this is a risk. I have seen this all too often that the PM does not know enough technically to know what is risky. And I think agile exposes risk better, but exposes it too late. i.e. when do you find out something cannot be done, once the sprint starts. So if this feature was schedule last, you have no room to move. Waterfall tends to schedule development in parallel, to try and expose risk earlier.

            However your statement: One of the scrum values is ‘commitment’, where the expectation is for the team to deliver what they say they are going to deliver to meet a sprint goal. is true, but ONLY at the sprint level. This is the crux of the problem with agile is how agile schedules things. Waterfall schedules requirements, development, testing, fixing. The waterfall team schedules amount of calendar time for fixing based on history. Once waterfall is done testing, they then try and acquire more resources to meet the fixing schedule.
            Agile doesn’t seem to ever schedule the fixing part of a schedule, instead believing the planning and setting of scope is so good nothing will go wrong, but when they realize they cannot do everything, they start dropping scope. It’s almost like dealing with a “Father knows best” philosophy. Like I said its great if you have no actual customer paid for features, as it allows you the flexibility to build what you want, or when the requirements are not understood. What I dislike about agile is telling customers they cannot put down detailed requirements, as that is “up to the developer”. Ultimately for agile to work very well in a customer paid for feature environment, every single possible use case the customer has needs to be documented. But once you do that you are basically part waterfall.

            which goes back to someone else’s comment “Wagile”

          5. SS

            No where in the Scrum guide says ‘Commitment’ is exclusive to sprints.
            Rather, Commitment is a way of being and thinking.

            To forward plan, Backlog refinement sessions are used to do this.

            It sounds as though you have not worked in environments doing agile properly.

          6. Agnostic PM

            you could be correct. The bigest difference I saw between the two methods, is when things went south in Waterfall, the organization went and got resources to make the commitment. In agile, it seems the philosophy is to drop scope rather than to get more people to make the commitment. And maybe that is more our organization than the agile process. It seems agile for us, by the time they know it is going south, more people cannot help because it is too late. It’s a little scary here, they are doing development two weeks before a release. In waterfall devlepment ends months before a release

          7. SS

            I would like to think that I am correct, I’m a qualified Scrum Master with over 5 years experience.

            A good agile team has a product owner that has a roadmap, and various other reporting to help them organise their backlogs

          8. Agnostic PM

            you may know what you are doing in your organization, but that does not mean it applies to all software development. I am simply stating that agile does not work as well for customer funded fixed feature, fixed schedule, fixed price contracts, compared to waterfall, IF the feature specification is known.

            You have not stated if that is the type of work your organizations contracts or if you are allowed to defer features/fixes with no impact. Or do you have something else going on.

            I’m more curious than anything

          9. SS

            I work for one of the biggest technology companies in the world.

            Yes I agree might not work as well for clients. With that said Kanban is better for that.

            Agile is better suited for Product driven environments.

  42. Zero327

    “ Incidentally, with the above in mind, Risk management in agile is better than waterfall where if the team are consistently not meeting their goals that in itself should be a massive red flag. Unlike a waterfall environment there is a higher level of transparency, where this is seen sooner.”

    That’s crap SS. Because Agile is working at break-neck page to execute on half defined user stories, it’s more prone, not less to introducing unexpected and unacceptable risks into the process. Waterfall is superior to a Agile at identifying risk, most especially in projects the Agile team hasn’t executed before. Pointing to a project manager as a single point of failure for risk is a trash cop-out, as in an Agile schema every individual of the team has potential to introduce risk, magnifying not reducing exposure.

    It is a well accepted shift from waterfall to agile that failures will happen more frequently and potentially more severely, supposedly in exchange for more frequent delivery of incremental releases.

    Agile performed by the book *can* be more transparent. It almost never is as is mentioned firms frequently do not execute agile with high accuracy or adherence.

    DO NOT make the argument that Agile is both faster and safer; much like a car speeding down the freeway at 100mph , agile lets you get to your destination faster. Whether your car is in one piece, you followed the route requested, you burned the full tank of gas in the process, or if it was safer are far less certain and usually run counter. Risk to reward, speed to reliability, agile to waterfall.

    1. SS

      Google ‘definition of ready’ – if agile is done properly then stories should always meet that criteria before being prioritised i.e. to reduce risk to the sprint goal, the necessary prep work needs to be done before hand.

      As a rule of thumb all stories should have enough information in them to be sufficiently worked on without many change requests.

      ‘ Agile performed by the book *can* be more transparent. It almost never is as is mentioned firms frequently do not execute agile with high accuracy or adherence.’

      I agree with this, a lot of companies are doing a bastardised version of it. Hence, if done properly, it works really well.


Leave a Reply

* Required