Slashdot Mirror
In Defense of Project Management For Software Teams (techbeacon.com)
mikeatTB writes: Many Slashdotters weighed in on Steven A. Lowe's post, "Is Project Management Killing Good Products, Teams and Software?", where he slammed project management and called for product-centrism. Many commenters pushed back, but one PM, Yvette Schmitter, has fired back with a scathing response post, noting: "As a project manager, I'm saddened to see that project management and project managers are getting a bad rap from both ends of the spectrum. Business tends not to see the value in them, and developers tend to believe their own 'creativity' is being stymied by them. Let's set the record straight: Project management is a prized methodology for delivering on leadership's expectations.
"The success of the methodology depends on the quality of the specific project manager..." she continues. "If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives -- all within the prescribed budget and timeline. Denouncing an entire practice based on what appears to be a limited, misaligned application of the correct methodology does not make all of project management and all project managers bad."
How do Slashdot readers feel about project management for software teams?
"The success of the methodology depends on the quality of the specific project manager..." she continues. "If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives -- all within the prescribed budget and timeline. Denouncing an entire practice based on what appears to be a limited, misaligned application of the correct methodology does not make all of project management and all project managers bad."
How do Slashdot readers feel about project management for software teams?
I've seen a bad project manager deliver bad products.
I've seen the other end of the spectrum where the PM worked with the devs, and was an all round good project manager.
Strangely, when a team works together, yo get a better result. When the PM is a dictator, you get an entirely different result.
The worst is when there is no project management. Things never get done, or you later find out that 6Month late project was because a new hire decided to swap X out for a
Actually I take it back. The worst is when the Shouty boss decides that shouting is project managing. Then the devs will deliver a mish-mash of shite built on a foundation of bitterness
YMMV
Signature v3.0, now with 42% less memory usage.
The primary function of project managers is to give higher management a feeling of control over things they don't understand. Maybe there are some unicorn PMs out there who actually serve to make communication more efficient, but in every place I've worked they're as useless as tits on a boar.
One PM at my current company spends 15-20 minutes of every meeting going over the color scheme of tasks in his kanboard webapp to make sure everything is properly classified. You'd think someone who's supposed to be a master of time management wouldn't waste everyone else's, but who am I to judge, my job involves doing actual work.
I can see the point for project management. But far to often in my eyes is the project management tool abused to meet unrealistic goals. Upper level management wants it done in 4 months, so middle management is not given the resources to do it but must find a way to squeeze all available resources into an unrealistic 4 month schedule with no room for delays or slip. Then upper management drops in new requirements, pulls people out for days or weeks for special interrupt tasks and expects everything to stay on the original schedule.
Sure the management tool is good for watching what is going on but feed back has to come from the bottom and unless a lot of margin was built in from the beginning, people have to be okay with slip and just use the management tool to understand where slip is happening and where extra resources are needed. The management tool is not a way to get a project done in unrealistic time with not enough resources. It is a way to manage the process of getting there.
FAce ID
You know, I'm a bass player (when I get the time). Nothing even close to, say, Flea, mind you, but decent enough. Ever heard the bass player jokes? We're dumb, can't play, have no talent, you name it. Why? Because there's a lot, an awful lot, of really, really crappy ones. Why? Because of how bands start out. The guy who can play guitar well does lead, the guy who can play passable does the rhythm and the one that can barely coordinate fretting and strumming gets bass. Because you can't fuck up too much there, it's easier and with a bit of luck nobody notices when you suck, can't hit a note or be in time. Bass is easy to pick up, hard to master, I can tell you, but it's easy to not fuck up too badly early on. And if you fuck up, someone's gonna pick up your slack and play the bass for the records.
Same with project management.
When you look at the resume of project managers, you find that many of them had a lot of hats so far. Not necessarily even as part of a programming team or a project. But project management is easy, at least to pick up. You don't really have to produce much. You have to "coordinate", and with a hint of luck the team will be good enough to pick up your slack and compensate for your shortcomings.
That is not true for all project managers, mind you. Like it's not true for all bass players. Some get there because they really want to do it and they are really, really good at it.
It's just the army of really, really crappy ones that you encounter throughout the years that color your vision badly.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Give me a project manager that understands software development and I will work with them to make a project successful
It can even work if the PM understand the core business that we are developing software for.
But, too many PMs seem to think that every thing is the same once that you wrap a project around it and as a result get more focused on meeting to talk about project parameters than making sure that everybody is set up to get as much work done as possible.
The question is simply, does the overhead of running a project deliver more benefit than the cost?
Having a 30+ year veteran's perspective as a developer, project manager, architect, and manager, I think the single most valuable thing a project manager must bring to the team is a sense and focus on the business context and value of the project. Some projects require moon shot talent and the requisite attention to the technological disciplines each member of the team brings. But let's face the fact that sometimes you're just doing the code equivalent of digging the outhouse hole. There's nothing to be done but get down in the middle of the mess and dig.
Jay Mumper
I think the real problem is that a lot of people who get put into project (or just plain old) management roles lack the aptitude, training, and/or desire to do it well. Some of this is the fault of corporate promotion structures that force good developers into management roles in order to advance up the corporate ladder. This squanders a good developer at the very least and potentially creates a terrible manager, especially if you get someone who doesn't have great people skills and would much rather be coding or working in their old role which they actually enjoyed.
I think another big problem is a tendency for project managers to be treated as bosses rather than a member of the team who's there to help facilitate the development process. I think people would like project managers more if they weren't viewed as task managers setting impossible deadlines for everyone, but instead someone who can figure out when things are expected to be finished and who can help the team remove bottlenecks. Putting someone in the middle management position where they have to try and force impractical schedules on developers is just begging for someone who'll be reviled on all sides and is only there for the pay check.
Project management is like anything else and not some kind of magically solution to all of a team's problems. You can use it responsibly and do it correctly and it's going to be beneficial to development or you can do it poorly and turn it into an impediment that everyone has to try to route around.
One year at my previous job, our manager was fired, with no real warning.
We went 6 months without a manager - just building boss that would walk in every couple of weeks. We worked with dozens of governments around the world to create tools to meet strict schedules and rulesets, matching with an ever-changing set of products used for each, while picking up new clients on a regular basis.
It was our most productive time in the history of the company, until they finally assigned a manager, who promptly decided to redesign the whole toolchain while we were in active and increasing workload. I just kept making new tools to automate tasks and allow for better use of everyone's time, and it actually went easier as me and the testing crew had to cover more ground.
Soon, I was the only person in my group doing actual real work on a rather huge portion of the code base. I was also coordinating with the other team members that were shifted over - but the new management was loathe to actually take my advice, since it made them look like less than heroic each time I had to correct their expectations based on actual customer exchanges over time.
Management can be great when they're actually covering for you - but just as often, I find they're just trying to shift perceptions and make a lucrative name for themselves - and spend most of the crucial time painting that picture rather than actually paying attention to the important details.
I understand the reasons for this - but it really is a sick process sometimes.
The first thing the project management is responsible for is the product, I suppose. Or at least they should work together (closely) with the product manager.
But what is the level you are talking about? I work in a small team (14 people), where five of us are responsible for five differentations of our software, and we have five people responsible for the more general part. These differentiations serve about 1000 users worldwide.
Our level of project management is about evolving the software either for features requests, re-factoring work, bug fixing or adaptation due to changing platform specifications.
We are all very close to the metal, but we do need some kind of project management, and our project manager helps to see the forest from the trees.
A good PM protects his team from interference by management, who otherwise interrupt and change their priorities every second day. At the same time, a good PM sets priorities, and adapts them to the developing reality, for example, when some task takes longer than planned, or when requirements really do change. With a good PM, developers get to spend more time developing.
A bad PM does pretty much the opposite of all that. There are a lot of bad PMs.
Enjoy life! This is not a dress rehearsal.
Only reason I ever worried about writing creative code is because the 'common' way was likely either copyrighted or under patent.
Outside of that, why WOULDN'T you write a section of code the simplest and most straightforward way possible? Not only will it make sense when you go back to maintain it later, but it will also help you figure out if said code is being duplicated elsewhere or if you can refactor at some later point in order to improve code density.
Good project managers are absolutely necessary on any project of any size. Don't believe me? Try this on for size; decide to build any little outdoor building - a shed, a garage, a and then send 6 people in to "creatively" see the project from design to finish with no project manager. Have fun!
Our level of project management is about evolving the software either for features requests, re-factoring work, bug fixing or adaptation due to changing platform specifications.
A lead designer or software architect is more appropriate to that.
Far too many PMs, apparently including Ms. Schmitter, have a 180 degree wrong understanding of the role of PM: they see themselves as responsible for managing down when the role required of them is to "manage up" and guide management to an understanding of what the team can and cannot reasonably accomplish.
Everyone thinks their code is the simplest and clearest way to write it, given their understanding of the problem, their understanding of the importance of the solution within the whole system, and their skill and experience in writing code.
Very few people deliberately set out to write complex or inefficient code.
"If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives -- all within the prescribed budget and timeline.
This qualifier If the project is being managed correctly is the reason why I slam all the evangelists of agile method or extreme programming or software project management... This give such a huge escape hatch rest of the assertion has zero value. Let us take a look at examples.
If the country is run correctly using proper communistic philosophy there will peace prosperity for all the citizens. No it is not some rhetorical statement I dredged up. I am from India and so many so called intellectuals in India make that statement. Ask, what about Russia? Cuba? Problems of China? They shrug and say "nah, they are not doing communism correctly".
The highly qualified and competent astrologers can accurately predict your life events. Give any counter example they just shrug and say, "these astrologers are not competent"
Every problem brought up by the developers or the management is dismissed, "you are not doing Agile right".
These guys have no clue about statistics, larger numbers and scaling issues. In a typical car or a mechanical system, there are hundreds of components making a few sub assemblies. The number of interactions you are looking at is 10^3 * 10^3 = 10^6 at component level and 10^2 * 10^2 = 10^4 at sub assembly level.
The software my team makes has about 1000 source/header files, about 10,000 functions, and about a million lines of code. The potential for adverse interactions starts at a million at source file level, 100 million at function level and a quadrillion at line level. This is one relatively small piece of mesh generation for finite element analysis. The FEM package our company ships has about a 100 exe files and dlls. If you open your mouth to say, "If you have done modularity right ..." you are hopelessly missing the point. This is insane level of complexity that is not addressed by a kind of process change. Development is already doing incredibly complex job, and the project managers come in make impossible promises to the upper management making our lives even harder.
I asked the Agile tool vendor to for a relatively simple, in my view, feature. When I commit a change to the user story state, check it before committing and do not allow me to commit illegal changes. Do not revert my change 15 minutes later and send me an email about, "the test case should not approved before the functional requirement has been accepted". The response, "minimum of 9 months and a huge change to the web API of the project management system and it would invalidate a few dozen mashups we have written". This joker is telling my upper management that our software certified for nuclear reactor design and aircraft aerodynamics can maintain a three month feature definition to delivery cycle. Is they any wonder most development managers want to find the nearest Agile evangelist and strangle him?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I've worked in a team that had a customer, a product owner, a product manager, a project manager, a scrum master, a senior developer, a junior developer, and a tester. I still have no idea why the company wanted to double up on management. The problems had started from the beginning. The product manager spent little to no time obtaining requirements from the customer, they allowed the customer to outsource the designs and then failed to engage them when it came to determining how the designs worked (i.e., the user stories). Note that even without the requirements, the timeframes were already set and provided to the customer. After the "initial" designed were delivered, the product owner and project manager vanished. The requirements gathering was left as a task for the project manager and scrum master; Neither of which wanted to engage the customer to determine the user stories - they made up their own based on how they they thought the app would work.
The developers were introduced to the project. They were shown the designs, and the project manager and scrum master started dividing the "user stories" between the developers. Note that the user stories contained the HEADING ONLY for a feature (i.e., "Show Page" or "Carousel"). The developers were then asked to "estimate" how long it would take to implement each story. The junior developer started to give time frames. I said that it was bullshit. I explained to them that the user stories should cover every aspect of the how the user interacts with the user - not just a title for something they've seen in a design. I told them that this must be a joke. I'll also take this time to say that I was the senior developer (yes a cynical developer who hates management).
Anyway, we were told that we should just start writing the app as their plan was to give the app to the customer often and then "capture" the changes as needed. Needless to say that the project has been going for over half a year, it was due to go to end user testing almost 3 weeks ago, as we're still getting change requests. We also haven't yet got an API to talk to, so everything we have done that requires data has been done with made up data. Note also that the developer that is writing the API is doing it in a way that doesn't allow any collaboration with the app developers due to the fact that there is no time to do it, so once we get the API, we're going to have to go through the code and either change everything that referenced our "fake" data, or have code in place that translates the real API data format into our made up format.
So to summarise, if there is a bad developer in a team the other developers will have to shoulder a bit more work as the code review process should filter out the bad dev's work. But if there is bad management in a team, the product is doomed.
it is only after a long journey that you know the strength of the horse.
A good team is one that manages itself. If project managers did their jobs and created functional teams, they'd be redundant. Hence they create problems to justify their own existence.
It's not just software development. Any successful and functional team in any industry can be prevented from attaining maverick status by the imposition of some corporate cock-sucking, middle management parasite that subtracts value from the enterprise. See also "diversity coordinators".
Project managers are unnecessary. Tech teams and business teams should be communicating directly. No need for a middle-man who costs money. Project managers will not understand either the technology nor the business as well as the other two groups. Projects need to be tracked but that can be done by the business and tech teams together with the right tools. Middle managers are a burden on an organization and project managers are just that.
Project management is a lot like design: if it's good, it can help a lot; if it's bad, it can hurt a lot. And you can succeed without it, but there's likely to be a lot of random flailing during the process.
I've worked with good, bad, and indifferent managers. One of the best managers I ever worked with was not-at-all technical, but knew people, and knew how to communicate and motivate, and how to remain flexible. The guy single-handedly changed my entire opinion of and attitude towards project management.
Our project manangers varied from "everybody wants onto her team" to "was peremptorally released from the project and company".
We kept the first kind, and could tell them from the second by looking at the dollar value of projects that suceeded. If the PM earned us $12.00 in a year, they were clearly doing something wrong (;-))
davecb@spamcop.net
Define "the simplest and most straight forward way to do it". That isn't the same for everyone. Some people like functional programming and streams of lambdas. Some of us find that style utterly unmaintainable. Even in your statement: "in order to improve code density"- code density doesn't mean its better and past a certain amount its actually undesirable. Dense code is harder to read, and more difficult to maintain without subtle breaks.
I still have more fans than freaks. WTF is wrong with you people?
Yvette Schmitter is fast becoming the woman that savvy females nationwide are turning to for business advice, lessons in leadership and the secrets of bringing balance to dating and relationships. Yvette has made it her passion and goal to redefine what it truly means to “BE YOUR OWN BOSS.” As a successful entrepreneur and former management consultant, she has made a name for herself at Deloitte as well as Cap Gemini Ernst & Young. In the business world Yvette has focused her talents on the health care industry, specifically on the issues impacting minorities, especially women of color. Ms. Schmitter has adapted her acclaimed approach to the skills of management and leadership into a foolproof plan for all aspects of a person’s life. She is currently in the process of writing her first book detailing her journey and discovery in becoming a real life “BOSS LADY.”
The New Jersey Assembly recognized her commitment to public service and named her Outstanding Young Woman Leader. While working toward her Bachelor of Science in Civil Engineering at Tufts University, she was voted “Leader of the Future” by her senior classmates. In graduate school, the President of New York University awarded her the “President’s Award” in recognition of her continued commitment to public service at the university; during convocation, Dean Robert Berne bestowed upon her the “Dean’s Award” for outstanding leadership.
While working as a senior consultant at Cap Gemini Ernst and Young, Yvette partnered with MAC Cosmetics and a local beauty parlor, Chez George to create a very special event to empower local battered women. The event, “New Year, New Do and a New You”, allowed the women to receive new hair styles and professionally done makeovers conducted by the MAC Cosmetics make-up artists. This combination of outreach and inspiration is exactly the kind of forward giving momentum that Yvette has dedicated her life’s work to
She is also a writer and regular contributor and commentator to nationally acclaimed websites and television networks such as BETTER TV.
She lives in New York City with a very special boy named Chance.
There is no mention of project management anywhere on that website.
Another source dated February 2015 says she is "Network Services Program Manager Government Programs at Emblem Health", which laid off hundreds of IT workers when it outsourced to Cognizant in April 2016.
I think your experience mimics mine pretty closely, working in the networking, hardware and support side of I.T.
The problem I've always encountered with project managers is they waste inordinate amounts of time and effort on systems to provide reporting or status update capabilities to their superiors. And yet, those higher-ups spend less time actually looking at the data collected than the whole team spent documenting it according to the required procedures.
Especially when we have a real fire to put out, such as a server crash or network circuit down - these people feel like flies buzzing around your head, trying to disrupt your attempts to fix it quickly. They're constantly pestering you for estimates on how long until things are fixed, updates on where you're at in the process, requests to call so-and-so to inform them that they can't do something or other while things are down, etc.
On the flip-side though? I appreciate the value in having a single liaison for upper management to speak with out what the whole team is doing. That's really the only time I feel like a PM adds value. I think most of the time, they just err on the side of trying to collect too much data in case their boss asks for it -- negatively impacting the team's ability to get real work done.
>Outside of that, why WOULDN'T you write a section of code the simplest and most straightforward way possible?
Because finding that way can take years of research. This is noble work if you can get it.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I often need to stop myself from writing my code too cleverly. Because when I do it makes it hard for other developers to maintain and I don’t want to own every line of code I right so I have to try to make it more easier to read, at the expense of a big O improvement, future upgradablity, or just the face I could do it in 3 lines vs 150 lines.
I am not saying that I am so much better then other developers, but I am going to think of a problem solution differently then someone else who has different experiences, so unless it is really needed it is best to go to a lower common denominator. It sucks but it needed for a successful project.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I know a couple of the PM's I've worked with on software projects in the past will be angry and disappointed at the subject line but I've never seen one that demonstrably added value to a software project/product I've been involved with - most have been detrimental to the overall effort. I can say that I do know a number of PMPs that are critical to hardware and marketing programs and have been vital to their success - I'm leading to a conclusion here.
First off, today it seems like getting a PMP certification is something somebody gets when they've been laid off and there are no jobs on the immediate horizon. I know that seems cynical but there seems a lot of truth to the statement - if you can demonstrate that you've worked slightly more than two years, take four or five courses and write an exam? In less than a month and a couple of thousand you too can have "PMP" on your LinkedIn profile.
I've taken the courses (through work) and they do have some value for general knowledge and if you are going to be managing a project which results in a physical object. Software is an entirely different beast and I believe it's impossible for really anybody to really properly plan out how a project will go. Unlike planning a piece of hardware, the required skills with efficiency are somewhat more nebulous (ie I can state with a high degree of confidence how many bricks at a certain quality level can be laid in an hour - I can't do the same for lines of code, it's highly dependent on the coder, development tools, libraries as well as pre-requisite work being done). To be fair, it's extremely hard to properly quantify coders - which makes planning and managing their progress difficult.
The best team lead I ever had, lived by the following set of rules for every project:
1. Set an expectation for the number of lines of working, debugged and documented code per day to something which seems ridiculously low (in his case it was 10 lines per day per coder) but is actually very realistic when you look at actual historical progress of the team/organization.
1.1. Plan contingency time at the end of the project (he liked 30% of the total project time) for new requirements and unexpected issues.
2. Coders work four days a week with one day for training and meetings. See "Management Time vs Maker Time".
3. Management can't talk to coders about their work. Ever.
4. Requirements/Specifications can't change through the project. That's what the contingency time is for at the end of the project.
5. Have an established test plan - In talking to him recently, he now insists upon implementing automated unit and functional tests that the entire software corpus runs through before any major release.
6. Base the plan and milestones on a reverse of the 80/20 rule - look doing what is going to be needed for the what is normally the last 20% and do it first
6.1. Pushing the requirement for the final UI design to the end of the project. Let marketing pay for prototypes and implement them at the end of the project. If the coders need a UI for testing, then they can cobble something together (and I know of two products where this became the final UI).
7. Accept that shit happens - I still get teased about putting in the statement "if (i = 1) {" thirty years ago in one of our projects which was discovered in testing in which the code mostly worked with the exception of one corner case that bugged a number of us (including him) into spending a week trying to figure out what the problem was.
You don't need a project manager to run a software project following these rules - you need a good, knowledgeable and forceful team lead.
Mimetics Inc. Twitter
Not much project management or the developers can do when corporate wants the software to be faster, cheaper and better, but is willing to settle for the first two.
The problem is for a successful project the management needs to be three jobs.
Person manager: they assign the resources to the job and make sure the right person is doing the right job at the right time.
Project manager: They keep track of the project and where it is at and notifies when a new task is needed and what it is.
Architect: They deal with what needs to be done for the project and if a rework is needed they address what needs to be done and what tasks are needed and address what skills are required.
Neither is above the other they have an important tasks that requires full concentration in.
Having done all three of these jobs I find doing 2 or 3 of them at once affects my effectiveness in the areas. Where I am doing just one job then I can be effective, because my bran will always be switching gears.
And having these jobs with different statuses is bad too because it means they will be in conflict with each other.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I always laugh when I hear someone using the latest and greatest boost. Then six months later they have to rip it out because it's the slowest garbage in history.
Junior devs tend to overbuild a project and sometimes even not junior devs fall in love with new tech.
I give my advice once and then move on. Sometimes people just need to learn.
The #1 complaint of most teams I've been on is that the PM sat around and rarely followed through on removing obstacles.
Project managers in most cases are just a layer between two sets of other managers. If you have a good manager, you donâ(TM)t need a project manager.
Project managers are there to make sure that interactions between different managers on multi-departmental projects happen smoothly, they should not manage or get involved with what exactly the IT department produces, just make sure that they develop a solution that fits the needs for the overarching system. Make sure that the cleaning manager talks to the datacenter manager etc. get metrics on every teamâ(TM)s status but when project managers get involved with individual team members they have failed.
The main problem with projects and project managers is that most of them are micro-managers, the project is too small in scope to be considered a proper project or there is a serious breakdown in managerial skills.
Custom electronics and digital signage for your business: www.evcircuits.com
If you have a bunch of programmers who can't focus and look at their phone every five minutes, then project management will help them out.
On the other hand, if you have developers who know how to self-motivate, and figure out priorities, then no, project management merely serves to make the suits feel comfortable.
The goal of good project management therefore should be to help the first group of programmers develop the skills of the second.
"First they came for the slanderers and i said nothing."
Project managers are usually hired by people who have no technical experience and no project experience. The result is about what you would expect.
And I've been in software development for about 2 decades. I've gotten more done the last year and a half than the decade prior combined.
> Outside of that, why WOULDN'T you write a section of code the simplest and most straightforward way possible?
* Because it doesn't report errors.
* Because failures corrupt critical data.
* Because it does not sanitize its inputs.
* Because it consumes far more resources.
* Because it's not testable without the
* Because it's not secure.
* Because "simple" and "straightforward" does not necessarily mean "intelligible".
* Because it requires a complex set of upstream features which have proven unstable.
The list goes on. Balancing the factors to produce robust, reliable, performant code can become quite a challenge.
> Project management is a prized methodology for delivering on leadership's expectations.
What?!
As a worker who has worked both with and without project management: The larger the group the more necessary it is to have. Not everyone is reasonable. It only takes one bad apple to ruin the process for everyone, after which project management becomes necessary. For us it was our director. We (the engineers) pushed for it because it was the only way to stop upper management from constantly imposing immense amounts of work on us to a degree that we didn't get weekends off and we had to stay at least until 8PM most days. I had dealt with not having project management for years with a small team and it had been fine, but once the team got larger and management got further away from the developers it became more and more necessary. I'm sure it also helps upper management know what's happening with the product as well, but I can't speak for that as I don't know.
...you produce.
If you're an independent software vendor (you make software intended to address markets/verticals - not a specific company) then PROJECT Managers are useful for coordinating deliveries and dependencies between teams (e.g. platform/middleware/sdk coordination) if you don't have high quality PRODUCT Managers. Sadly, finding quality product managers for an ISV is both very difficult and very expensive. Product Managers at ISVs are supposed to have domain expertise - unfortunately, many do not.
If you're a product development group that builds software either for internal corporate use, or a services group that builds software at the behest of an external customer then you're likely to use a form of Project Manager called "Product Owner" - which is supposedly some form of "Product Manager" but it really isn't. The person is basically responsible for tracking the project (the job of a Project Manager) and managing inputs taken from the customer - which makes them think that somehow they're Product Managers...
Ironically, it's much easier to come across a quality project manager today than it is to find a product manager that has any idea what their job actually is. Most modern product managers (most, not all) seem to think that they exist to 'ideate' and sit back and let people discern what exactly they meant - "What's an MRD?" "What's a PRD?" Lol...
YMMV
Loading...
its really funny to hear that software devs / engineers creativity is be held back by PM. what about mechanical and electrical products? I think that without some PM things will go off the rails pretty fast, not every company can be a valve where you just get to work on the stuff you want to work on.
If you want maximum creativity go be an artist. if you want to make products that are reliable and fail safe then PM needs to be part of the process.
Much better dealing with him than with management.
I can tell him the options, he can talk to management to figure out what they want.
Management can ask for 20 features, I can tell the project management we can only do 2 in the available time.
He can decide which ones we need and tell management to suck it.
Yeah, much better working like that than directly under management.
Truckloads of shitty ones with a few professionaly inbetween?
Sounds plausible. :-)
We suffer more in our imagination than in reality. - Seneca
Best project manager I've ever worked with made everything go incredibly smoothly, even on tough projects with frustrating clients.
How? She asked us a simple question: What do you need to get this done?
We told her what we needed, she accommodated our requests with plenty of time to meet deadlines and milestones, and then she trusted us to get our shit done while she met with the client and other management for progress reports, etc.
PM is just like anything else - it can be done shitty and it can be done well. And just like with anything else the shitty/useful ratio is roughly 80/20. I've encountered my share of both types.
However, I can imagine that with a proper development pipeline and a professional small team, PMing is only required in very small doses at specific points in time. Set up a modern toolchain and everybody on the team will do a bit of everything anyway. As a Scrum Master on one larger team I did tooling on the side. My PM was testing and helping assembling assets (we were buliding a game). We had a great crew and Scrum and PMing and such was only required roughly 30% of the time.
I wouldn't shun PMing entirely though.
For instance, budgeting and corporate politics needs a dedicated person to deal with - that's classic PM territory. A good PM can be worth his/her weight in gold in these areas.
So no, I'm not pissing all over PMs just yet.
And you shouldn't either.
We suffer more in our imagination than in reality. - Seneca
I obviously don't have backing stats for these, but at least the consesualized opinion around my geographical location (for context: the European start-up industry) is as follows:
Now these 2 might seem contradictory - one for each sides of the argument - but reality is managers or not on the team, it doesn't matter finantially.
I know of exponentially growing companies that do not have appointed managers, but they will still use agile. I have also seen successful startups that took management very seriously from scratch, and projects only worked because of that solid management. I myself work in a company that, despite having well-defined management structure and using scrum, velocity - the real juice that scrum should be outputing to managers - is simply neglected. The reason we keep using scrum is a mixture of keeping peers on their toes between each other, and staying hip, and for what it's worth, it kinda works.
Worst of all is when you see big companies with super-duper complex process workflow diagrams for inter-corporate ladder behavior, and applying those to software teams just because some consultancy service needed the contract or because some official certification was necessary for a project, and then, over time, the entire bottom level workforce, which was certified, moves on and gets replaced with cheap, unexperienced labour. Do they expect managers and/or PDF documentation to keep standards? That is utterly unrealistic, and that is the biggest lie managers sell. Good management will not only value the process - it will value process-savvy developers, allow conditions for them to stay, or conduct process-aware hiring if it becomes impossible to keep the best of the certified crop. Some say there is a culture of job-hopping in IT, but I believe there is a culture of not knowing how to keep your IT.
Bottom-line is manager presence in a company is becoming a cultural decision: some companies have used them for so long they will never see them as harmfull, while others are either open to new ideas or simply fresh out the oven they take the plunge and go management-less, at least in the middle of the pyramid. Top level management will never disapear - there will always be someone steering the ship and profitting the big bucks. Or else we would be seeing exchanges flooded by cowork-based companies, and soon enough communism would take over :D
I prefer to write if statements like "if (1 = i)" exactly for the reason it won't run. However, for javascript linting they call it yoda talk and it is indicated better the other way for readability. Normally I would think that is ok, but these types of bugs can do some pretty nastly things are are often very hard to catch.
THIS. If I hadn't comment in the topic already, I'd be modding this up.
I actually just said something simillar earlier - about software being a different beast. I actually think that beast is integration - the fact that minds will be minds, not one alike, thus code will rarely converge into one cohesive purpose (in part also because that purpose is never the same, even with the best req spec). But "the internet is vast and full of libraries" is just another take on the same conclusion - we are all on the spectrum regarding code, and that really slows down cooperation.
Well, that and the "continuous bug" obviously. That set of rules is nice and all, but with most hip culture now being around continuous [whatever it's called this week], you basically don't have the slightest chance to get ALL planned features in time, because you WILL have bugs haunting you, some of them simply too complex to even say they're edge cases. And since there really is nobody better than you to solve your bugs in the team, it never made sense to make room for dedicated maintenance on the team. Teams want accountability. And did I mention we are all autistic about code? Yeah.
Every post you right is less easier to read then most, witch are more easier to reed sense they no how two right end you doesn't.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I've been Yoda coding since 1986, when I first made that mistake.
Mimetics Inc. Twitter
I much prefer a compiler or code analyzer that simply flags an assignment where a condition is expected as an error or at least a warning. Then it doesn't matter which form you use, you get told about the problem either way. And personally I find the yoda-talk form much harder to decipher when I'm trying to parse or construct compound conditions.
Devops and Agile teams are now more focused on decentralization of control where teams have almost full control of the entire stack from conceptualization to deployment and production. This is quite the opposite with regards to the common methodology of Project Management where control is top down. We can see a clash of motivation here where management wants to exert control and development Teams want to become more agile but PMs always get in the way so to speak (as tradition goes). But devs know better that if they want to move fast and be productive management has to get out of the way and instead focus on goal setting and stop micromanaging development teams.
"If the project is being managed correctly by the project manager/scrum master..."
Scrum master is a person appointed to make sure that the scrum methodology is being correctly executed in the scrum team.
Scrum master is not a fucking manager. Please stop turning them into one.
As a developer with 20+ years of experience, I've worked with a number of product managers, both in official title and in effective practice. I cannot say I've ever seen one which was a positive factor for the organization and/or quality of the products.
However, that is not to say it's not possible; I firmly believe that it would be possible to have a PM with a positive impact. Moreover, I think one of the other comments is also correct: the potential value is somewhat also dependent on the quality and self-motivation of the developers being "managed". It's a much higher bar if the developers are proven capable of independently creating quality products, and conversely a lower bar for developers who need lots of oversight to be productive. If you have "bargain" developers, they will need management and oversight, and even a "bad" PM will likely improve the outcome.
All that being said, I'd say on _average_, PM's don't add much, if any, value to the development process if you have "good" developers. I've seen a number of [nominal] PM's which add considerable negative value. Personally, I'd prefer a "good" PM to no project management, but no project management is preferable to a "bad" PM, the ratio of good PM's to bad PM's is low, and "upper" management will inevitably select for "bad" PM's. I'd speculate that this combination of factors is what leads to the hate for PM's in general.
What you just described, especially in realistic expectations of performance, allowing for contingencies and conducting verification through testing, such pretty much describes established practices in engineering.
> Not every task actually benefits from creativity!
Indeed! At my own company, every week somebody is costing us time and money by trying to come up with a creative way to do something rather than looking up how others have done it successfully for decades.
Most recently, we needed to handle many concurrent TCP connections. We wanted to fire off a request, send other requests on other sockets, then come back later and read the responses, asynchronously. This is instead of sending a request, waiting for the response, then sending another request. Developers creatively brainstormed different ways to do this, coming up with mostly very bad solutions. I pointed out that many concurrent TCP connections has been some many times before, sometimes by people much more knowledgeable than us. The Apache web server has multiple different multi-processing modules to choose from, with many sources describing how each works, and the advantages / disadvantages of each.
Last week they were coming up with creative ways to script getting the IP address of a newly launched AWS instance and adding its IP to the whitelist of another security group. I pointed out we're not the first company to want two AWS instances to be able to talk to each other. Perhaps we should check the documentation. Sure enough, AWS security groups allow you to whitelist access from another security group - no need to get the IP at all. Just click the button once, which then allows all instances in the scaling group to access the protected resource.
I've explained to them that there is a well-defined way to represent many-to-many relationships in SQL databases, known-good ways to represent hierarchy, etc. We don't need to creatively invent any of this.
Is she somehow confusing applications development with the game of rugby?
Any PM who achieves euphoria with regard to their team is either wasting money, missing scope, or slipping an undefined schedule.
His reed sounded true for me, maybe you're listening wrong?
A scrum master is not the same thing as a project manager. A scrum master simply sets up the meetings: daily scrum, backlog refinement, sprint planning, demo, and retrospective. During these meetings the scrum master doesn't do anything and isn't responsible for delivering anything. These meetings are for the Team and the Team is responsible for running them.
"How do Slashdot readers feel about project management for software teams?"
Project management for software teams is JUST like everything else- there's good and there's bad.
I've seen good PMs keep a team focused, keep friction down, and step in to resolve all sorts of problems that cropped up. These PMs were invaluable and their effect on the software teams was positive, sometimes overwhelmingly positive.
On the other hand, I've seen shitty PMs wreck software teams that were previously functioning well,. I've seen them increase strife and uncertainty, or generally just fuck shit up (for want of a better term). Their effect on teams were miserable and destructive in the extreme.
I mean, hello? It's this way in every field. There are good bakers and bad bakers, skilled dentists and incompetent dentists, honest police officers and tyrant police officers, great mechanics and shitty mechanics...it's this way in every field or practice or endeavor known to man. Why should program management be any different?
Just cruising through this digital world at 33 1/3 rpm...
I believe you meant to say "your" :-)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Project management is a prized methodology for delivering on leadership's expectations.
Yeah, I think that sums up the problem with project management these days. It isn't so much about managing the project, as spouting the right buzzwords and showing the agile-compliant burnup charts that make the boardroom feel like they're in with the hip crowd here.
Project management is a thing that can be used by management.
I like small business. I like when a team has one clearly defined person in charge who is responsible for the product, the project, the budget, the sales... all of it. When things are unclear and people go into CYA mode, bad things happen. Project management in CYA mode is a bad thing.
Also, this BS about software being different from everything else needs to end. It's similar enough to other discovery based fields to be managed similarly. It's much more predictable than something like biology research, and much less predictable than electrical engineering. So what's so difficult? If you've not worked on a project where you had a team of biologists (and their goopy labs) as part of the development, you should try it some time. It will really make you appreciate writing software.
If you have a manager who insists on unrealistic results, put them in charge of a drug discovery project some time. There are times when business goals and reality simply don't intersect. That happens all the time in many different fields, not just software development.
Anyone who doesn't "do" is a waste. But the project manager's job is to stop other people and issues wasting more time, while wasting as little themselves as possible.
A good PM is someone who claws back more time than they waste. (Their meetings to track progress, ask what's blocking etc. all take time, but if, and inevitably when, things stop a dev, the PM should be there to sort things out.)
In an ideal world, where the devs are good and motivated, the designs are good and complete, and the customer is good and helpful - a PM will only waste time. I'm fairly sure we don't live in an ideal world.
The way I see it the problem with project managers is the same as with any other kind of manager. A good manager can do more good than any single worker they manage, but at the same time a bad manager can cause way more damage than any single worker they manage.
Where this becomes a problem is that a bad low level employee is relatively easy to get rid of and may not need an immediate replacement, a manager is much harder to get rid of and needs an immediate replacement. The end result of this is that a bad manager will stick around for far longer and replacing them may not even be something their employers even consider. What's worse is that despite management not being something everyone is suited for, many people still expect to eventually become managers even if they're wholly unsuited for it. I've seen more than a few cases of people wholly unsuited for management roles get into management positions, completely fail at it, and then even after they've been removed from any management positions, often by being fired, they refuse to work any jobs where they aren't managers.
The only solution that I can really think to this is for organizations to streamline the process of getting rid of bad managers and figure out a way to convince people who are found to be unsuited for management roles of their unsuitability for the job. However specially the latter is a very difficult thing to do when people have egos and don't like for it to be deflated by people saying they're not suited for the most high paying jobs.
"Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."
Software PMs get a bad rap because the use case is often to be a buffer between incompetent management and a misguided and badly staffed development team (usually because of incompetent management). PMs pay for themselves x2 or x3 by making it possible for the devs to get done on time, under budget and often with fewer defects - if they can actually practice their craft.
-- $G
"Project management is a prized methodology for delivering on leadership's expectations" it really is, and that is exactly why it is terrible. I'm a senior manager myself, but the most common thing killing software teams is management's ridiculous expectations focused on the wrong priorities. At the last Agile conference I attended, managers proudly described how they created workflow templates for their scrum teams so they would know exactly how to work efficiently. The best development environments are created by engaging developers and letting them work on the problems both with the technology and the process. Do what you can to help them, remove barriers, and stay the hell out of their way. If your project manager can work by presenting goals, staying high level and avoid micromanaging or setting impractical milestones, they can do fine.
Allowing if (i=1) depends on the language, and only brilliant languages prevents you from doing them (ie. golang).
THIS. Exactly this.
A PM is not a glorified secretary, checking out checkboxes, repeating non-productive status meetings ad nauseum, wasting everyone's time and focus.
A PM is not a dictator, micromanaging everyone's schedule and interfering with how to best solve problems.
Ideally, a PM is out of the way, but asking what people need and accomodating. In practice always needed and helpful.
In that regard, a PM also get ideas what people are working on accomplishing, and can connect the dots nobody else sees, even innovating newfangled methodologies like agile development releases and testing on such, but only if people find it helpful (buy-in).
I've been on a project where this was successful, just by PM listening to everyone, not just the local dictators, and presenting ideas so that it can be implemented in practice with minimal fuzz. Sure, it'll require a bit more time investment and coordination, but it helped to sort out issues before final delivery phase, which meant higher quality before final testing. However, this does not suit all projects/people, and it's tricky to predict which is best suited.
How? She asked us a simple question: What do you need to get this done?
Good for you. Here is how that conversation normally goes.
"What do you need to get this done?"
"We need X people for X months plus XYZ to create a testing harness (we do embedded systems which need some kind of HIL for testing usually)."
"You can have half that. Sound good? Also, don't bother me when you're working nights and weekends; I'll be at home with my family."
When there are a lot of stakeholders or process to be moved through, a project manager to keep track of all of that is really key. This is a skillset most people don't really have and a good project manager is a life saver.
At the same time, lots of development shouldn't be treated as "project" work. Tight collaboration between design, development and product leaders are the core. You want project managers to get out of the way there. That's more creative work and no gannt chart is going to help.
Failure to recognize whether what you are working on needs PM is a pretty common failure pattern. A PM doing a lot of work where they shouldn't results in negative contribution, and missing them where they are needed tends to result in failure to deliver.
Case in point: working on a current project where the project manager thinks he can dictate the solution such as the business requirements, functional requirements and technical specifications. I have told him more than once to stop defining a solution to a problem, stop offering technical advice and STOP talking to the business about the tech.
This dudes project plan was illogical, it was not consistent with any kind of BA, requirements building, development or testing. The build task consisted of a single entry with no drill down to the high-level tasks (ten high-level development tasks, where four had pre-req's of the others being complete). The Project Plan should not cover the implementation of these tasks, but being able to track the development at the project level was pretty important.
The project team except for the PM agreed with everything I said; the QA team's constant complaint was that there was no way to plan for their testing because there was no break down, no ability to plan testing around build task completion. No time built in for testing scenario review between BA, Developer and QA. Somehow magically QA was supposed to get it perfect first try with no other input.
The issue with this guy is he looks at the "manager" part and thinks we all work for him and that he is some kind of God of everything which is the exact opposite to what he is. He is a coordinator, he is there to help make sure the different teams work effectively together and based on our needs to put together a project plan facilitates planning and tracking of the different teams responsibilities.
Unless the "project manager" has worked in the role, I can only say they're not very useful. :| ) I've worked with, but every single one of them has the same negative in common.
I've stopped counting how many PMP's (
They don't know how, nor how long, things work. They don't know jack. They know buzzwords, but that's it. They know how to schedule normal everyday things, or ideas, but they have no idea how to schedule things in the field they're "managing" unless they've done the work, which they probably haven't, since they took project management.
It's like having a band member manage a show choir concert, and nobody dares say anything because they'll be told the band member already has a plan. :|
Nope, there is no such thing in as Project Managers in Agile. Same thing with BAs, SAs, and testers. Just a Scrum Master, Product Owner, and Team Members.
Basically, the same like some self-imposed yoga teachers. There is nothing to teach in yoga, there is nothing much to manage in software. Of course, one could always invent absolutely necessary rituals, practices, routines and then attribute every single positive thing to these rituals. Religions perfected these techniques for a millenia.
Are you aware that some people speak native languages other than English?
Not only am I aware of that, I also know they typically write better than jellomizer. Why do you ask?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
"prized methodology" - no, you mean 'prized METHOD'. can you please stop using words that you don't know the meaning of?
I've had experiences with both the good and the bad. My first software project went through 3 project managers before I quit and moved to a different project. The first PM worked remotely and I never really met him at all. The second was a decent manager but his strengths weren't in software project management so he wasn't really good for the project. He also had too many long meetings (45 minute "stand up"?) which wasn't helpful and felt like it just wasted our time. However, he was a really great help for me professionaly, so, I like him. The third PM seemed to be moving the project in the right direction but I didn't interact with her much. When I moved to a software company I encountered a much better implementation of the Agile method and a PM who knew how to run a quick stand up and help us find the tools and help we needed to move forward with the project. She was great. We just hired a new PM to replace her and so far she has also been a great PM. So, I've had the good and the bad so I can see how some mid or upper management person would think you don't need a PM or why a dev might get frustrated with the process. But, at the end of the day, you need a good process and good design. It is really hard to do that without someone taking on the role of project manager.
I'm seeing a definite cultural shift where developers seem to think that they're better than everybody else, and can do everyone else's jobs. It's massive Dunning-Kruger situation, and it's unfortunately not going to get any better because companies keep trying to woo developer mindshare, so schmoozing developers and perpetuating this problem is in their best interest.
The fact is is that the average developer is NOT a system administrator. They don't know best practices for maintaining systems, ITIL, etc. They more likely than not are completely ignorant of SecOps (I mean FFS, it's 2017 and we're still dealing with SQL injection attacks). But despite this, I'm seeing more and more products as self-contained black box docker images or whatnot. Docker is a shockingly unstable system that, while great for certain development tasks like continuous integration and testing, is flat out dangerous to use in production unless VERY carefully controlled and monitored. NodeJS is so unstable that they actually think an 18-month LTS is pretty darn good. They do this not because it's better, but because it's easier for the developer. They don't think/care about the poor sod on the other end that needs to support the product in production. Heaven forbid that the developer's company, for whatever reason, stops supporting the project they made and the end-user sysadmin needs to somehow maintain the software or otherwise tweak it to work with other software.
Nor are they a project manager, and yet you have idiot blog posts lamenting how useless PMs are. Sure, there are going to be lousy PMs, just like there are going to be lousy sysadmins and lousy developers. But that's a far cry from denouncing an entire job field. A PM can make or break a project, and a good PM is worth their weight in gold. Project organization is NOT easy, and the larger the project, the harder it is.
Where are the blog posts that point out how stupid developers are? Just from my own personal experience I could write posts about all sorts of idiocy performed by supposed 'senior' developers. Like storing fixed dollar amounts in a float because it was "more convenient" for the developer to use, or iterating through a hashmap to find a value. The number of examples is virtually limitless. And yet NOBODY is saying that we should get rid of developers, because that would be stupid.
Too many developers really need to just grow up and realize that they arn't as good as they think they are.
I'm amazed I'm almost half way down the comments before someone said this.
A good PM takes work away from you. Examples where a good PM can help:
- "These specs don't really cover what's meant to happen if we do X. Can we get someone to elaborate?"
- "I tried calling person X in sector 7, but can never get them to actually spend any time to explain Y to me. Can you help?"
- "Manager X came over and told me I need to do Y. What's my priority here?"
- "I looked at X, but I can't do much without Y. Where do we get that from?"
- "I honestly don't know who to ask for X, any ideas?"
- "This ticket asks to change X, but that's changed 1000 times in the last 3 months. Can we apply some common sense here?"
From the manager's POV, the PM should be reporting progress, taking changes and reporting what delta that will result in, and telling the managers to get the hell out of the techie area of the office if they get lost and wander in. Shit happens and projects get late, at which time it's the PM's job to clear as many barriers to delivery as possible and to tell management whatever they need to hear that they feel like sufficient urgency is being applied.
Put me in a team like that and I'm all good. Put me in one where no one is fulfilling that role and I'm a lot less productive, and a lot less happy too.
The opposite is a shit PM, or generally weak management around the tech teams. In those worlds, techs get micromanaged, you get asked to bring "solutions not problems" and a (what should be simple) blocker becomes a major source of stress and delay as it goes around and around the layers of management so they can all "add their value".
I agree that there are some project managers that aren't as good as others. However the one thing I've learned is that a project manager is only as good as the information they are given.
The developers shape their project manager. If you want your PM to have a deep understanding of your project and how it works...you'll have to invest the time to get them to understand it to the depth you desire. If you want shorter meetings you should have an understanding of time/effort to get your work done. If the PM isn't working in a way that works for you then find a professional way to discuss it. A good PM should be flexible and understand everyone works differently.
I'm not a developer rather a systems administrator who jumped into project management for a few years, and jumped back after missing break/fix life. My biggest gripes with the job was that I felt like a middle man getting yelled at from both sides. Which is exactly the reason for the position.
Developers don't want to get micromanaged and execs want direct answers to questions. Which is where the value of the PM resides. With communication being the key skill. Talk with your PM and understand how they take in the information, and what their standard is for providing it.
I can assure you they're tired of meetings, asking 'who just joined?', and saying 'I'll get back to you on that'. They want to streamline information, and avoid the noise.
Ms Schmitter has committed the "No True Scotsman" fallacy by stating that "If the project is being managed correctly..." which essentially means that if the project manager gets the proper results, than the project manager will get the proper results. Or nonsense. As a retired project manager, I agree with all the other Slashdot comments about how projects and teams go right or wrong. Those anecdotes are all valid. Just don't say that project management done right produces projects done right.
The worst is when the Shouty boss decides that shouting is project managing. Then the devs will deliver a mish-mash of shite built on a foundation of bitterness
In most jurisdictions, shouting at people can be considered a form of assault. It can be the basis for criminal charges or a suit under tort law.
It probably would be ok to shout at somebody to get their attention in the event of immanent physical danger, but shouting at somebody because the manager is frustrated or stupid or incompetent is never justified. Even if an employee makes a mistake, shouting is seldom if ever part of a solution consistent with the law. For a manager to shout at employees is most likely extremely stupid behaviour.
In many jurisdictions, superiors in the management chain of command can be held negligent in tort law for failing to get rid of a manager below them that engages in this sort of practice. By analogy, tolerating this sort of behaviour is like failing to get rid of a hazard on property one owns, which is especially important on a commercial property - businesses are generally held to higher standards than individuals.
Corporate law can also come into play here: there may be obligations to the stock-holders that are violated if managers are engaging in stupid and unprofessional behaviour, which is generally what is happening when shouting at employees is something tolerated in the workplace.
Further, in many jurisdictions, businesses are required by law to provide a safe and healthy workplace. Shouting at people is generally not consistent with that requirement. Stress has medical implications, with physical consequences. Exposing people to high levels of stress in the workplace is no different than exposing them to toxic chemicals, or high levels of noise, or radiation hazards.
Organizations that have a Standards of Business Conduct are also likely to take a dim view of managers engaging in this sort of behaviour, even if immediate legal liability is not an issue. Failing to have Standards of Business conduct can be held against companies in some circumstances (certainly by jurors), and failing to follow it can be almost as bad. This can create long term risk of legal liability - and may well disallow the operation of insurance that would otherwise protect against liability ('lawsuit insurance').
In US law, rights "retained by the people" (9th Amendment) or "reserved to the people" (10th Amendment) may also be applicable: nothing in the Bill of Rights prevents the application of such rights against private entities.
In short, how dumb can you get?
What about a team 30 developers? Can they work without a project manager? There may have been bad teams with some bad project managers which we cannot use to calculate the efficiency of having a project manager for a team of software developers. Try using this free task management tool available at https://fluxes.com/
Here's my take on it. Yvette Schmitter is correct, as far as that goes.
"The success of the methodology depends on the quality of the specific project manager..."
On the face of it this is good. However she's a PM herself and this puts her into a bit of a conflict of interest. Is a milkman really going to tell you his milk is no good? And down-rating actual workplace experiences, much discussed here on /., doesn't help. Thus her defenses seem overly defensive.
"Project management is a prized methodology for delivering on leadership's expectations." Really? Because IT projects are routinely and notoriously challenged or fail entirely. Not the majority, but far more than makes the "leaders" happy. This statement reads like a direct quote from the PMBOK, drumming up certifications from the PMI.
"...what appears to be a limited, misaligned application..." Well isn't that special! "Mistakes were made, blame is shared all around, what's important is that we've all learned and grown!"
Oh, we were being serious? All right then. The Software Engineering Institute out of Carnegie Mellon University has been tracking project failures (more formally, success rates) for years. The statistics are compelling (these are from memory, accurate stats should be looked up from the source). Just as a big picture, roughly 1/3 of all IT projects fail, totally. Another 1/3 of IT projects come to completion but miss their timeline, their budget, or both. Only 1/3 of projects are unqualified successes, meeting timeline, budget and user expectations.
Does this sound like a "limited application"? Does this sound like a message a PM with self-interest should be delivering?
PM should alleviate https://en.wikipedia.org/wiki/... between stakeholders and software teams
Casteism