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."
To quote Dwight D. Eisenhower, "In preparing for battle, I have always found that plans are useless but planning is indispensable."
If you go into a major project without some sort of project management, it's not going to end well. However, the management of the project needs to be flexible enough to adapt to the changing environment. Decent project management will see when things are under resourced, and help to fill in those gaps (if possible), and should keep the project going in the right direction.
...si hoc legere nimium eruditionis habes...
1. project managers that graduated from the school of flagellation. the ones that think assigning a firm date to every goal is the only way to ensure it gets completed, and are willing to waterboard you for not adhering to the holy calendar. some of what we do in systems engineering -- like deprecating old systems or rolling out your cloud provided buzzgasm solution -- is highly technical. if you're not willing to draw diagrams or at least document how and why we arrived at some of these goals, youre just another manager.
2. project managers that ignore dependencies. sometimes other teams need to get involved to accomplish a given task or objective and if youre not willing to make the call, then who is? securing time from the beleaguered network guy, the storage zombies, or the NOC is technically under your purvey. if we make it all the way to the calendars release date and you havent done the needful when it comes to taking to other teams and understanding the business structure, then we can hardly be blamed.
3. companies that insist on contract-based project managers. they arent around long enough to learn the business or the systems in place, so they have very little incentive to participate fully in the project lifecycle. these shitlords get away with floating from company to company and doing very little at all.
Good people go to bed earlier.
"The Mythical Man-Month" by Fred Brooks.
This should be required reading once a year for ALL direct and indirect management of any engineering or software development team.
Again with the "Oh, Look at what I found, managing complex tasks is hard!" How many times will we be blessed with the same insight that Mr. Brooks put on paper way back in the 1970's? My guess is "just once more!"
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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).
The problem is that upper management doesn't understand that status reports have a non-zero, non-trivial cost. When a project gets into trouble, the number of status reports and meetings increase, which surprise surprise, slows down progress. Also, software development is non-linear for at least part of any non trivial project. Refusing to accept that fact has caused problems for decades. Sometimes as a developer, it feels like management is working against us. Does any of that sound like a useful part of running the business?
"Those that start by burning books, will end by burning men."
Project Management isn't suited for Product development.
Most project management methods are based on some fallacies.
1. The users of the product knows what they want: The truth is they don't know what they want until they can get their hands on it, and know if what they see if they like it, hate it, or have a some tweaks that are needed. No matter how many meetings you have with static pictures and blueprints. The user just doesn't know what they want until they can get their hands on it.
2. Development of modules have a start time and a complete time: Function X may take 2 days to develop. Because it is prerequisite for function Y. However after function Y is completed and used function Z, You need to go back to function X, to get the data prepped for function Z, but you couldn't put that code in for function Z support until you have completed function Y which needed X. Coding isn't linear, they are parts that needs to be addressed and fixed, causing other parts to be reworked or adjusted.
3. People are interchangeable: A coder is a coder right. Well no. Some of them are really good at doing Database calls, while others are most comfortable with the HTML and JavaScript. While there is an other one who is most comfortable with the Middle tier code. Sure all of them may be able to code all the parts if needed, but for the most part each ones is going to be a specialist in particular parts. This means not all people are used qually or performing each task as efficiently as someone else.
4. People have lives outside the project: While working most people may get called to take a look at a different project (bug fix a previous completed application) they may need to sit in a meeting for a future project. Also they can get sick, have family emergencies...
5. Coders just code uniformly: There is a degree of artistic pride every coder uses. Everyone will approach problems a bit differently, they may be arguing with the Architect for them to be doing something a particular way or they will just ignore, misinterpret, the internal parts of the spec, and just make sure the output meets the specs. So this often creates some conflict because the internal changes may affect something else (timing, system resource, readability...) So we may need to redo the function, or just adapt the rest of the stuff around these changes.
Most PM policies are based on manufacturing processes. Where the goal matches the outcome. Product Development the outcome is usually different then the initial goal.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
My favourite manager (now retired) had the same philosophy. You'll find a similar theme amongst most people's favourite bosses.
He was an ex-Army (AU) warrant officer and wouldn't hesitate to rip you up like a drill sergeant if it was your fault, but equally wouldn't hesitate to throw it back upstairs if it were a problem with senior management or sales. If any customers were being unreasonable with his engineers, he'd practically teleport to site, sit everyone down, look the customer in the eye and calmly ask them what their business case was for being difficult with a vendor.
He also had a mostly hands-off PM style, he'd just bump into people during breaks at random points, ask a couple of questions, move on. Ask him where the pieces of project were at and he could list them off like a human Gantt chart just based on those queries. But woe betide you if you didn't inform him of any looming problems before they became serious, or if you tried to push blame away. If you came to him with a blunt statement along the lines of "I fucked up, here's the issue, I think this could solve it", he'd bend over backwards to get it sorted.
I've since tried to model my own management style after his - definitely not as successfully.