In Defense of Project Management For Software Teams (techbeacon.com) 160
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?
Bad product manager / bad product (Score:5, Insightful)
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
Re: (Score:2)
Grr: "because a new hire decided to swap X out for a " ... inappropriate tech
Re: (Score:3)
Similar results occur when a senior developer tries to expand capabilities or switch toolkits to one that they've heard of and want to explore, but which has no one else in the company has any familiarity with. My personnel get tasked with cleanup after _many_ such adventures: I'm quite proud of them for integrating, or helping companies decide to discard, many technologies that are ill fitted to their needs.
Re:Bad product manager / bad product (Score:5, Interesting)
What I find funny, as a developer, is the idea that "developers tend to believe their own 'creativity' is being stymied by [project managers]."
Every time you look at code and have a visceral NIH (Not Invented Here [Syndrome]) response, that is your own creativity crashing up against the author of the code's creativity.
When you see good clean code and don't have any NIH response, that implies that the author resisted the urge to be creative, or simply isn't a creative person.
Not every task actually benefits from creativity! Even if creativity is valuable to a programmer overall during the process, while actually writing the code perhaps it is harmful to the result! Most devs might never be happy with project management, including when it is working well and being effective.
Perhaps they'd do better to focus on claiming about any shouty bosses, instead of resisting project management?
Re: (Score:2)
Of course, there's the opposite of NIH.
If there's a massive framework that even bringing it in causes memory footprint to skyrocket, and you just use one little trivial function in it, better to write your own trivial function instead.
Re: (Score:3)
That's why I try to stay on tiny microcontrollers.
There isn't enough RAM or ROM for most frameworks.
You might have 1 framework to choose from across a product line, or else you write your own.
If you want 2 features, I give you... 2 microcontrollers!
Re: (Score:2)
Perhaps you should learn what a linker is or how class loaders work, idiot.
Most of the interesting bits have been done before (Score:5, Insightful)
> 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.
Re: (Score:2)
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.
Re: (Score:3)
>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.
Re:Only reason I ever worried about writing creati (Score:5, Insightful)
> 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.
Re: (Score:2)
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 ex
Re: Only reason I ever worried about writing crea (Score:5, Funny)
Re: (Score:2)
His reed sounded true for me, maybe you're listening wrong?
Re: Only reason I ever worried about writing crea (Score:2)
Re: (Score:2)
Re: Only reason I ever worried about writing crea (Score:2)
Re: (Score:2)
A competent PM with good people and management skills is worth their weight in gold. A bad PM is like a boat anchor dragging the project down.
Re:Bad product manager / bad product (Score:5, Insightful)
I came here to write exactly this. I've been a salaried team member, technical leader, team leader and contractor. I've worked with good PMs, bad PMs and no PM.
A good PM works to make the project run smoothly, working with the team to identify and mitigate risks, schedule appropriately and communicate effectively to higher levels of management. With a good technical lead, team lead and PM (one person may fill more than one of those roles) many issues tend to get identified early and resolved or mitigated.
A bad PM often tries to be a dictator and/or lies to higher levels of management. They tend to actively impede development (whether through malice or more likely incompetence).
No PM tends to result in a floundering team. Someone needs to do PM-like activities even if there's no formal PM role, and if there's an identified team or tech lead they tend to get stuck with it in that case. It's usually better IME to have someone who enjoys doing PM activities and is fairly good at it than have someone try to do it in their "spare time".
Re: (Score:2)
Which is part of the problem. There are too many bad PM out there and not enough good ones. So we are better off not having them as the net effect of PM is worse the. A world without them.
Re: (Score:2)
Our products require software, firmware, hardware, possibly ASICs, and manufacturing. No one development team is going to be able to manage all of that; the coordination of work between the departments doesn't just magically happen over lunch. So that's what a PM does. Well, there's Project Management and Product Management, sometimes a Program Manager, all called PM, and they're all necessary and should align. These PMs also have to deal with all that the departments listed, an some have to deal as well
Re: (Score:2)
Re: Bad product manager / bad product (Score:2)
Re: (Score:2)
However, no PM at all will drag the company down too. Someone has to do this job, and if that person doesn't exist it will be informally created (ie, the developers' own manager or team lead will take on the duties). That's because you can't just gather developers in a circle and expect that a product will spontaneously emerge.
So the danger here is in encountering a bad PM and erroneously assuming that PMs are not necessary.
Sun used $ in sucessful projects as a criteria (Score:2)
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 (;-))
Re: (Score:2)
Project leadership triad. (Score:2)
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.
Re: (Score:2)
This same problem exists for other managers as well, by the way: line managers / middle management. They need to be good at various jo
Re: (Score:2)
PM is about communication, in both directions. When done well, management has realistic expectations and R&D focuses on those things that are important to management, including schedule.
When done poorly, it doesn't matter what position you're looking at, the more people they touch, the more they damage progress. PM being in the thick of things does have the capacity to destroy a good team, when they're doing their job poorly.
Re: (Score:2)
Right, there must always be some sort of product management, even if the devs call it something else. Even if devs are locked in a bunker with no guidance, they will either create their own informal product management or nothing of use will come out of it. Just the very act of saying "We need to create a product" is rudimentary product management; and that gets expanded as the details grow ("like X but better", "customers want feature Y but not Z", and so forth). The rest of product management is about ke
Re: (Score:1)
The worst is when the Shouty boss decides that shouting is project managing.
So you're saying there's a different way to manage projects?!
In my experience (Score:1)
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
Re: (Score:3)
The PM is where the disconnect happens, but in a bad environment that's what the upper managers want.
The simple test: Your schedule is blown. Everybody can see that critical path is longer than the remaining schedule. Does the PM go to management and marketing to start managing the late delivery and/or missing features that's GOING TO HAPPEN or do they start cracking whips and blathering about '110%', expecting someone to pull a solution out of their ass?
I think the PM role should be on the project tec
Re: (Score:1)
You only know you are on track when known issues using known techniques to address them are left to address.
Anything new needs to be addressed first. Before you do 300 million dollars worth of 'easy' stuff to stay 'on track'. Unfortunately, with big projects like that raising issues will often get people fired. After a company fires two or three people who raises issues, then people stop raising issues and just participates in the train wreck.
Re: (Score:2)
1% of projects have something genuinely 'new'. Most risk in projects is new staff and/or tools, not so much new techniques. There really isn't very much new under the sun. Those things do need to be put first and kept off critical path as much as possible.
If the team doesn't understand the problem, stick a fork in them. They're hopeless. Need to build a throw away prototype to make the problem concrete, touch base with the users then revisit the analysis and plan.
99% of 'new stuff' is kids reinventing
Re: (Score:2)
A stable toolset is like a stable team. Everybody want's it, but nobody really has it. On the other hand, chasing every fad is a fucking nightmare.
You're not disagreeing with me, I said: 'Most risk in projects is new staff and/or tools, not so much new techniques.' What was the last language/system you ran into that wasn't just doing the same thing, differently? What % of that was different (vs. well known things)?
I know of a team that spent _years_ working on a Java/Swing app (back when Swing was _com
Re: (Score:2)
Put another way: 'When you see the game is rigged, all you can do is vote with your feet.'
Re: (Score:2)
There do exist good PMs, very good at letting people do what they need to do, but also reminding about priorities. They also get a good sense of how the team may underestimate or overestimate themselves, and can know without being overly nagging when things are going wrong and to chase help. They also can be extraordinarily helpful at managing external dependencies and logistics. Good PMs seem never to have to ask anything and yet still know your answer. Having such a quality PM is a real thing and can
Re: (Score:2)
Big company vs. small company.
Small company: The PM helps the team succeed by facing inwards to the team, understanding what's going on, making thing happen in the right order and setting expectations and goals.
Big company: The PM faces outwards, keeping the rest of the company out of the way, triaging incoming interruptions and maintaining a clear runway for the developers.
Just my humble observation after 25 years designing products.
I'm not a software developer, but .... (Score:2)
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, s
I can see the point (Score:1)
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
Re: (Score:1)
Depending on the size of the company top level management almost never understands the technical details in a project. The worst thing management can do is act as they understand and promotes unreasonable expectations on the project team. Over 30 plus years I have worked with project managers of all types.
Type one is the PM who just walks around the office several times a day and asks if you are done yet. This PM type also tends to think the more meetings they have leads directly to a successful project end
faceid (Score:1)
Bad apples make the basket look bad (Score:5, Insightful)
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.
So PMs are sort of like PHP developers? (Score:2)
Truckloads of shitty ones with a few professionaly inbetween?
Sounds plausible. :-)
Re: (Score:2)
Think of it as something akin to a lateral Dilbert principle [wikipedia.org]. Instead of promoting someone so he can do no damage to the project, you move him to a position in the project where the damage he can do is limited.
The big picture (Score:1)
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 don
The real problem (Score:2)
Re: (Score:2)
If developers are that "good" they are typically kept in development to ensure continuing product quality. Promotion to management is usually driven more by articulate ambition than any particular technical skill, stimulated by the pay and perks which are mostly a relic of the unskilled labor era, especially for lower levels of management.
Product (Score:2)
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 fea
Re: (Score:2)
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.
I take exception to this statement - a project manager is not responsible for the product, a project manager is responsible for the process used to develop the product.
Bad project managers think they're responsible for the product and will try to steer the product to meet their goals (ie delivery on time with the initially set costs and resources) while bumping the needs of product management and the customers.
A good PM (Score:2)
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.
Re: (Score:2)
What you're describing is what I would consider a good first line manager/team leader - not a project manager.
Stupid circular reasoning. (Score:3)
"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?
My experience (Score:3)
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.
Project managers are unnecessary (Score:1)
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.
It's a lot like design (Score:2)
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.
Author is NOT a Project Manager? (Score:5, Interesting)
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" [dapulse.com], which laid off hundreds of IT workers when it outsourced to Cognizant [healthcareitnews.com] in April 2016.
Re: (Score:2)
She lives in New York City with a very special boy named Chance.
Sounds like something I'd say about my dog.
Re: (Score:2)
Re: (Score:2)
Touche.
Re: (Score:1)
She sounds very good at marketing-speak and self-promotion.
Re:Author is NOT a Project Manager? (Score:4, Insightful)
Sounds like she is very good at projecting a persona, telling people what they want to hear, and promoting herself--someone to be avoided at all costs if you're interested in actually getting any work done.
Re: (Score:2)
Wow, that sounds a lot like someone who makes a living out of evangelizing management, especially when that management is female. And of course, no mention of real-life software development project management, which was kinda the point.
I think, like all "macro" managers, this specific person still neglects the intricacies of software, and the relatively novel art that is attempting to manage software development.
I for one see software project management as the management of minds steering in the same direct
Re: (Score:2)
Specificity will depend on how specific the consultants knowledge of what they want to hear is.
No such thing as a "good" Software Project Manager (Score:5, Insightful)
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.
Re:No such thing as a "good" Software Project Mana (Score:4, Interesting)
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.
Re: (Score:3)
Re: (Score:2)
I've been Yoda coding since 1986, when I first made that mistake.
Re: (Score:2)
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.
Re: (Score:2)
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 s
You just described a good engineer (Score:2)
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.
Faster/Cheaper/Better (Score:2)
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.
Most PMs do suck (Score:2)
The #1 complaint of most teams I've been on is that the PM sat around and rarely followed through on removing obstacles.
Multi-manager systems are always bad (Score:4, Interesting)
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.
How good are the developers? (Score:3)
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.
Re: (Score:2)
If you have a bunch of programmers that can't focus and are looking at their phones every five minutes - why do they have a job in your company?
Re: (Score:2)
In my experience, nutbag narcissistic project managers destroy the self-motivation of developers
That seems to happen more often than not.
bad managers are an HR problem (Score:2)
Been Without A PM For 1.5 Years (Score:2)
It depends entirely upon what type of software (Score:3)
...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
I like my project manager (Score:1)
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.
Re: (Score:1)
Who's pissing all over the PM occupation?!?? (Score:2)
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. M
The numbers should speak from themselves (Score:2)
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:
Scrum master is not a manager. (Score:2)
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.
WTF is a "Scrum Master" (Score:2)
Is she somehow confusing applications development with the game of rugby?
Oh please (Score:2)
"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
The problem with managers in general... (Score:2)
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 b
PM = Bad Use Case (Score:2)
If there is a "project" manage it (Score:2)
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 r
Project Manager title != bad. People make it bad (Score:2)
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
project management for software teams? (Score:1)
"Project management is a prized methodology " (Score:1)
Good project managers are great for software teams (Score:1)
Developers think too highly of themselves (Score:2)
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.
Fallacy (Score:1)
Information Asymmetry (Score:1)
Re: (Score:2)
It's nice that they have certis, hang them in the loo, so you got TP in case of an emergency.
The difference between good PMs and bad PMs is whether they "have" it. In my experience this is one of those positions where "soft skills" are more than anything you can certify or quantify. What you need here isn't someone who knows milestones and PM tools but someone who can talk, can read and handle people, can argue and convince and can navigate the corporate structure well.
Try to find a (sensible, not some BS)
Re: (Score:2)
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.