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