Slashdot Mirror
Do You Buy Into Management Methodologies In IT?
albert_tam asks: "I don't appprove of 'management methodologies' and I feel that things like ISO, TQC, Kepnor-Tregoe, CMM, 6 Sigma, etc., aren't worth the time it takes to learn them. There are also those self-proclaiming-MBA-bearing IT experts, who spout off about these everyday in our office and earn big paychecks. The result? It's not important. By the time everybody in the office is forced to get started with these management methodologies, those 'so-called' Quality assuring IT consultants are already gone. The thing is, do you buy those management methodologies? How do you draw a line between IT & management concepts without hindering your daily work? Let's hear what you have to say."
Umm, you seem to have forgotten something. The IT department is not there to give a warm home to a horde of unwashed nerds with no social skills. It's there to support a business. That's it - if it wasn't for the business, there would be no IT. End of story. If you aren't supporting the business, you aren't doing your job, no matter how many MP3's on your hard drive or how many times you've recompiled your kernel.
If the MBA says you're doing something wrong in your shell scripts, ignore him/her. If the same person says you aren't giving the business the support it needs, then shut the hell up and pay attention, you might learn something.
Honestly, I'm sick of geeks thinking that knowing how to program is the only skill that matters. What would the world be like if railroad track layers thought they knew better than anyone where the trains should stop?
Exactly! Letting everyone do their own thing works if everyone is competent and even compentency is not enough. See here
I am a lowly programmer like everyone else but I have talked to CIO's and they know the best programmers can be 10 or 100 times or more productive than the worst programmer on staff. But the CIO does not care because if the gifted programmer creates a killer product if that product( I use product as internal program used by companies since most programs fall under this domain.) may only be maintained by that programmer, not the lowest common denominator. That killer product is actually worthless. Why? Because if only person who may be able to maintain the program is the creator and this person is such a great programmer, then their time should be spent developing on new projects, not maintenance. The CIO is most interested in everyone following a similar set of rules and standards with minimal diversion from the standard (but deviation can be ok but there is a limit which is left to discretion).
If everyone follows the same rules and standards, what are the rules? That is where CMM and the others come into play. Instead of creating another standard, follow the work someone has already done. More likely, the following will happen: Take the best pieces of each standard and water them down so the common folk can understand them. KISS is the key.
I read an interesting article on software methodology on Martin Fowler's site (www.martinfowler.com). In this article he discusses light weight development methods and compares a few existing methods.
Basically his arguments boil down to this:
Traditional, so called heavy weight methods, are bad for creativity because they drown developers in a sea of bureaucratic documents.
No method is not good either, because in larger development teams anarchy leads nowhere.
Any method should be based on good assumptions. One of these assumptions should be that development and creativity of developers is inherently unpredictable. Therefore there is no point in building a requirement specification because by the time you have implemented, the requirements will have changed. The so called lightweight methods fowler suggests, are all iterative methods. They involve a lot of testing and frequent milestones.
The methods he discusses all follow this pattern. He even mentions open source and mozilla as examples of light weight development methods.
Jilles
The problem with most methodologies is the people who apply it. There is an old joke: "What's the difference between a methodologist and a terrorist? -- you can negotiate with the terrorist."
A methodology must be flexible. In the projects I work on, my company is spending millions of dollars on outsourced mega-applications. One of our big management issues is vendor management. I've got to say, that some of them are dicy, but in the air transportation industry, there aren't many vendors to choose from.
The Space Shuttle programming team, has one of the most rigorous methodolgies in the world. They also have one of the lowest defect rates in the world.. Coincidence? I don't think so.
This is a boring sig
I have often considered writing a book with my subject line title. I have seen shops with no standards to shops with "standards" so ridged you can't get a report change done in 3 months. The only approach that I have seen work is hiring competent people that can work directly with the clients. This allows management to stay out of the way and let the coders do their job unhindered. All the other schemes I have seen simply slowed the process down without providing the promised benefits.
When you place tight controls on your technical staff. What I have observed is, they still make the mistakes, but it takes a really long time to move them into production. This translates into no quality increases and performance decreases. Doh! I bet if you checked an IT shops performance statistics before and after these controls are put in place. They would prove this point.
Bottom line is, let the programmers do what you pay them for and don't design methodologies for the lowest common denominator.
--Scott
--Scott 8-}
Vintage computer games and RPG books available. Email me if you're interested.
Why do people complain? Because there are often not enough hours in the day to take care of the details required by these methodologies, and to get the "other" work done. Many folks would rather "get on" with the coding (or whatever) rather than take care of procedural chores. This is the wrong attitude. The procedural chores are part of the work. CS people seem to be the only folks who don't recognize this.
Would you want the biotech labs or pharmaceutical companies to "get on" with their work while ignoring procedural safeguards? How would you like the ironworkers erecting a skyscraper to "practice their art" while ignoring the directives of engineering inspectors?
The IT methodologies put the science back into "CS".
It seems we have a few MBA-cum-IT professionals here at /. And you will all have to excuse me because I am in shock at how proto-typical my workplace is in this regard. Alot of you will believe I want a 'glass house' to 'protect my job' - that is flatly untrue and way off base... anyway..
I work at one of the Big Three(Two/Five/whatever) Auto Companies. We presently have 2 major 'initiatives' to 'transform the company into the leading provider of quality automotive products and services'. Every week our Big-PHB (CEO Jack Nasser) sends an email and the tagline is "Customer Focused and Shareholder Driven, Jack Nasser". This same joker has decided that the entire company must impalement a few things:
1) FPS or Ford Production System; an all massive project requiring all aspects of every function of every job in the company to be detailed, described, documented, proven, repeated, audited (etc (like your standard ISO schtuff)). Every job must be accompanied by visual aids and 'error-proofing' techniques. Also, the 'enterprise pyramid' is to be inverted where the 'orders come from the bottom' (bottom being rank&file labour). and much much more...
2) FTPM or Ford Total Preventative Maintenance - a system that uses the above, and other techniques to predict machine failure and try and act pro-actively. (isn't this what 'qualified tradespeople' already do?)
What is the point of telling you all this? Well, firstly this method's are mandatory for all facilities to employ be they manufacturing, accounting or IT. I would like to know what any of this mess has to do with running an IT dept? When you try and run an IT dept like a widget manufacturing plant you will soon find that they are not the same. When some bone-head MBA decides that an IT dept needs to deploy these systems he may be right- but probably not... I understand the importance of documentation/auditing/logging in an IT dept; the concepts are universal.
When the dust clears from all this crap there will be a few likely outcomes:
A) this asshole will be out of a job because it will be discovered that his 1/2 dozen projects (6 sigma, FTPM, FPS etc etc) are all bullocks.
B) Some other asshole with his 1/2 dozen idiot schemes will have convinced the self-preserving toadies (just below the last asshole CEO) that he will "transform the company" into "insert your asshole tagline here about irrelevant crap"
C) ANY economic downturn will shut all this crap-spending down.
D) People will be loosing jobs now that they have all been braking their backs showing everyone how to do their job (meaning: "Look Bob does this this and this. Lets fire Bob, give 'this' to Steve, 'this' to Mary and forget 'this'... Muhaha saved another $75k for the 'shareholders'")
E) IT depts. everywhere will be forced to shift gears and make progress in this new set of 'corporate transformation strategies'
Bottom Line? Attention MBA's: Leave the IT depts alone! We know what the fuck we are doing, YOU DO NOT, if you did, youd be a member of the IT DEPT. Computer Systems have a basic 'trueness' about them that defy your 'underlying principles of operation' - they operate the same in whatever company is employing them. Be that a shoe manufacturer, insurance business, widget painter or ?????. We do not care what you are talking about in your email, we do not care what data we shuffle, we do not care what crap you stuff in your office documents or what the data in our RDBs 'means'. Its all really just chars and ints (ultimately just bits) and its doesnt matter what it says... so listen up Mr. MBA: Leave us the hell alone - IT people can see through your nonsense, can hear the desperate lies in your office meetings, the fear of being found out for the shill you are is written all over your face... we can also read your email and disclose your interest in collecting lesbian-albino-midget p0rn... if not, we can frame you. If you want to spend money on something to improve the IT dept? Drop all this crap, provide better wages, more staff, more training, more Co-ops and clerks this all serves to give us more TIME. Remember: its all just chars and ints - and you dont really understand....
I dont advocate chaos in IT depts where everyone does as they please -- that is untrue... anyone OUTSIDE of the IT world may think without these "paradigm shifting dynamics" that this is what happens - that is not the case - people INSIDE the IT industry know that systems have a way of telling US what to do, what is the proper way to maintain them, what is the proper way to code programs, write maint scripts for them et al.... oddly it all comes very naturally. Please don't interfere with our quest for Nirdvana.
"Total Quality Management" has thus far been an excuse for managers to reoganize everything into micromanaged environments while claiming to empower employees. It's Dilberting of the highest order.
ISO9000 on the other hand, turned out to be, while not stellar, a dramatic improvement to workflow around a different company. Aside form the fact that we needed ISO compliance in manufacturing in order to sell our products to certain european governments, it finally forced a lot of the "Fast-and-loose" policies to be codified. Suddenly we had to document what we were doing - everyone, from the manufacturers to the sysadmins to the developers to the product support people. Often tedious, yes, but it ended up helping a lot - all the code had documentation, system changes were recorded, etc. While most of our IT staff had done this anyway, we finally were able to convince the management-types that 1) we needed a decent repository for this sort of data and that they too were responsible as well for knowing what was going on.
Possibly the best side effect is that managment suddenly realized that they'd lose their ISO certification if the ISO document storage systems went down, so they became very interested in uptime and redundancy - approving the requests for redundant systems that they'd shot down for expense reasons many times before.
The weirdest part of quality systems is that in the end, they're just codifications of common sense. Document your changes. Keep records of your processes. Centralize your enterprise-level information. Stuff that every IT person would consider a no-brainer, but stuff that your average marketing droid would've never had any exposure to.
----
----
"I used to listen to Null Device before they sold out."
I think that the whole article deserves a big -1 Flamebait. Your comment, however, has valid points.
I think that the major problems with IT management are as follows: /sarcasm. When machine code can't be generated, the SE has specified the object or procedure so much that it there is not much room or reason to be creative when developing the code.
Bad Managers -- Let's face it, as the IT field grows older, the management styles will evolve until it grows better. New things ideas and methods are already being tested (Some very successfully, e.g. Donna Shirley's Mar's Global Surveyor). Eventually the bad managers will be weeded out, or at least we will have the definition of a 'good manager'. I don't think that the standard MBA program is capable of producing good IT managers, but MBA programs are changing. Math depts. around the USA are starting Industrial Mathematics Master's degree programs that provide a 'Technical' degree similar to a MBA (intense business classes combined with intense mathematics/programming).
Expensive Labor -- Face it, large companies would rather have software generate code than have programmers write it. The kill the good programmer, as AC puts it, because they want to pay less for programmers. I work for a large government contractor, and the 'Systems Engineer' approach is to use expensive packages to layout OCDs and OODs and then the packages generate code to be used in run-time systems. This effectively eliminates the programmer all together, with the exception of someone to go in and fix all of the machine generated code. Every programmer finds it fun to deal with machine generated code
Finally, I don't claim to be an expert on IT management. I find it an interesting area to learn about and I welcome all comments from people who disagree with me. I do recommend Donna Shirley's book, however.
Keeping
One thing that is painfully clear after spending a short time in the land of Dilbertesque cubicle landscapes is that acronyms encapsulating total management methodologies are the bane of the clueless, talentless bore. Analyze the situation and use common sense and good wisdom to architect an individual solution for the particular peopleset and project needs? Nah. I'm using SuperSilverBullet-ECST-9 2001! Five times the productivity in half the time....or so the consultant says.
Speaking of that what you're talking about here is consultants trying to push themselves into every organization for nice big fat paycheques. ISO 900x is a hilarious set of standards that basically come down to : Document and be consistent. GENIUS! Yet there are millions of consultants on this planet making billions of dollars to go in and say "Document and be consistent. Here's a word template that would take a normal man about 3 minutes to make. That'll be $125,000 please."
What this reminds me of are software development "methodologies" that could be summed up as this : Lots of idiotic, no talent Visual Basic programmers feel contempt for their more talented coworkers so they propose and push and fight for a lowest common denominator sort of system that removes the benefits of being talented. You carefully crafted an algorithm that solves XYZ? So what did you preceed it with a completely useless blobbogram and 1,500 pages of documentation? If not then gosh you're a dangerous man! I mean how can your code be any good if some code-monkey who should be in the field of burger flipping but lucked into a programming course can't understand it?
In my experience, the "Mangement Methodology Obession" began in the 80's and unfortunately stayed with us to this day.
The basic idea of looking for ways to improve results, measure results, make rational changes, and plan ahead is great. I'm all for it. I'm one of those people that, in general, feels people do not think or plan far enough ahead.
The problem is everyone began looking for a magical solution. This methodology doesn't work? Try this one! Everyone was looking for the Magical Productivity Bullet of Total Quality, to the point where they didn't even give the methods they were trying a chance to work.
There are good ideas out there - but they're being used as crutches, quick fixes, and outright scams. There are plenty of lousy fad ideas out there as well, and thanks to all the obscufation, it's hard to tell them apart.
I distrust any new "method" unless people can show it's worked and worked elsewhere and explain WHY it worked. Usually good solid planning, review, and testing will do the job just fine.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
99.5% of management methodologies are marketing booshwah for consultant's services. The other 0.5% can make a huge positive impact in the effectiveness of a company.
Simply implementing Deming's 6 points would revolutionize the way most companies work - for these points prosletyze respect for the individual. Proper use of these ideas results in a corporate culture where each worker contributes to and takes pride in the result of his work. There is no more powerful way of improving the health of a company.
The result is merely implementation detail that is the easy part. The hard part is putting the 6 principles into action.
The problem is that too many workers (and middle managers) have been through the management fad of the month; TQM, Re-engineering, etc. and have felt the effort was wasted. It's really sad to see the baby get thrown out with the bathwater.
You know, every hacker should read "Zen and the Art of Motorcycle Maintenance".
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
It's already been mentioned that the alternative to methodologies is letting everyone do their own thing. I'd like to point out that this is the same fear people tend to have about Open Source. "How are you ever going to manage people who each have independence of thought and action?"
The real problem underlying suspicions about Open Source and working with a lack of prescribed methodologies is an inherent lack of trust by the management for the people doing the work. This could come from an underlying knowledge that, as corporate managers, they typically have no real value added themselves. They know that their jobs are inherently deceitful at some level, and therefore project that world view onto other people. People without purpose must be managed.
But guess what? Even in a methodology, you're only going to achieve anything at all by the willing cooperation of the managed. You have no choice but to trust them, even though you may put structures in place to hide that fact from yourself. Take away the methodologies, and you have to look the fact straight in the face: you can't make it happen without them, but they sure as hell can make it happen without you.
God save the Queen^H^H^H^H^Hmanagement!
I haven't encountered any purely management methodologies. But I have come across, and used, several development methodologies. Every single dev meth has had a lot to say about the management of a project (some more than others).
Development methodologies are superb. If you can get everyone in the team in agreement on a methodology, then you can create software quicker and better. These has been shown academically, in the workplace, and in my own experience.
What you don't need are bureacratic methodologies. If you spend your whole time writing documentation, drawing diagrams, tracking your time and other morale destroying tasks then the methodology sucks.
If you spend all your time writing high quality, self documenting code with repeatable tests - that pass - then your methodology is good, although I suspect you're lying about the 'all' your time bit
Personally I prefer iterative methodologies (DSDM, FDD, XP) and my current project is using Extreme Programming in anger (for the first time - it's scary). XP does tackle a lot of management issues - not least of which is, "What does the manager do?" question. It points out where traditional project management tasks are handled by the methodology and where managers can add value. It deals with measuring and tracking project progress, and using those measurements to determine future project progress (thus allowing better estimation and hitting release dates). It also covers testing, including unit tests and functional/acceptance tests.
So even those I would describe it as a development methodology, it is also to a large degree a management methodology, and more importantly can greatly add value to your team.
So methodologies are essential in any business type development. What you call them isn't important, but having them, and making them easy to understand and easy to use, is.
Of course, if you have political managers (i.e. they're in the game for their own benefit, trying to promote themselves all the time, not working together or for the company) then any methodology could run into problems. So pick decent places to work where people are motivated and committed (which doesn't mean 70 hour weeks - you can be committed and go home at 5pm every day - especially if you use a good methodology to control your projects).
In the open source world something like XP could be hell to implement. Something like DSDM probably goes out the window too - how do you prioritise requirements when people send in the code that meets the requirement at the same time as they send in the requirement. But successful open source projects have their own methodology too - they have mechanisms for reporting bugs, they have source control, they usually have a single person (or committee - but either way, a single point of responsibility) for determining what goes into the next release. How much of this constitutes management I leave to the Slashdot audience; that it is a methodology (however primitive) I will state with certainty.
~Cederic
ISO9000 done correctly is usefull, done badly it is worthless. Far too many managers think that ISO9000 is all about labeling things and having lots of documents - it is nothing of the sort.
Take a bug tracking system, can you:
Say with certainty that if a bug has been reported than you can find the report?
Know whether the bug has been fixed or not?
Know who fixed it (or is supposedto) and when and what they did to fix it?
Say which versions contain the bugfix and which do not?
If you can answer yes to each of those questions then your bug tracking system is fundamentally ISO9000 compliant.
Imagine that you are developing some software, do you know:
What is to be implemented?
Who is supposed to be implementing each feature?
What the design is?
What changes each person has made?
If you can answer yes to each, then your development is fundamantally ISO9000 compliant.
Quality has become a management fad, but at its heart, it isn't. It is about being organised, taking pride in your work and having a professional attitude.
If you build a system, is it a black hole that your sucessor will curse you for or is it well documented and well run, something your sucessor will thank you for.
ISO9000 tries to codify a professional attitude. If you have done chemistry, you will be familiar with the report format, Title, Aim, Introduction, Materials, Method, Results, Interpretation, Conclusion. It is simple, but it ensures that you say all you need to say and don't waffle. The idea is that you should be able to give the report to another chemist and they should be able to follow what you did, why you did it and be able to replicate the experiment without any surprises. The same holds true for other quality methdologies, your documentation should answer all the questions that a skilled professional might have.
ISO9000 as it was intended is very good, but ISO9000 as management fad is as bad as any other management fad.