Slashdot Mirror
Is Project Management Killing Good Products, Teams and Software? (techbeacon.com)
New submitter mikeatTB writes: "For software development, no significant developer activity is predictable or repetitive; if it were, the developers would have automated it already," writes Steven A. Lowe, Principal Consultant Developer at ThoughtWorks, via TechBeacon. "In addition, learning is essentially a nonlinear process; it involves trying things that don't work in order to discover what does work. You might see linear progress for a while, but you don't know what you don't know, so there will be apparent setbacks. It is from these setbacks that one learns the truth about the system -- what is really needed to make it work, to make it usable, and to make a difference for the users and the business. In other words, the dirty little secret of software development is that projects don't really exist. And they're killing our products, teams, and software." Lowe continues: "Projects, with respect to software development, are imaginary boxes drawn around scope and time in an attempt to 'manage' things. This tendency is understandable, given the long fascination with so-called scientific management (a.k.a. Taylorism, a.k.a. Theory X), but these imaginary boxes do not reduce underlying complexity. On the contrary, they add unnecessary complexity and friction and invite a counterproductive temptation to focus on the box instead of the problem or product. This misplaced emphasis leads to some harmful delusions: Conformance to schedule is the same thing as success; Estimation accuracy is possible and desirable enough to measure and optimize for; The plan is perfect and guarantees success; The cost of forming and dissolving teams is zero; The cost of functional silo hand-offs is zero; The bigger and more comprehensive the plan, the better; Predictability and efficiency are paramount."
I've been around for a number of years in the dev trade. I've seen good and bad projects. When project management is done well it makes a world of difference. Everyone knows what needs to be done without needing three meetings a week just to figure out who is working on what. The deliverables get clearly defined, and change management is enshrined and accounted for. Working in this environment is awesome. Now, do project management badly and your project WILL be over budget and over schedule. Nobody will be happy and it will be a crap job. Nobody will be especially clear what the deliverables are because change management is not accounted for and you have moving targets. The team spends more time finding who to blame than just fixing the problem. My opinion - if you are using the wrong tools, you'll have wrong project management. (i.e. Asana is a task tracker, not an asset manager, resource planner, time log, or credential manager... Task tracking is only part of the equation).
I first hit this in the 80's. Our company was the first to use microprocessors to replace walls of computers with boxes maybe 3 cubic feet (1x1x3), that by the way did 10 times the work the walls of computers did.
One quarter the defense budget got cut and we went from growing 40% to 20%. 20% growth sounds good to you and me. But to the bean counters it was a layoff. That got the expected profits for the quarter back in line at the expense of future growth and morale.
I have to admit, that first layoff got rid of a lot of deadwood. But the second, third, and fourth really killed the company. Those that were either marginal, or not good at politics, got canned. Those that were good at their jobs looked around, said "um, how about no", and left.
I got hit in the 4th layoff, and only got laid off again once since I learned the signs. The second time was a start up failing, I hadn't yet learned how to read a balance sheet.
MBAs don't understand the morale hit they take when they do a layoff. They may say they do, but they don't. I've survived several layoffs, each time morale went to hell and a lot of good people went searching for more stable pastures.