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

Comments

Too often a crutch not a solution

[Badgerman]

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.

Management Methodologies

[the eric conspiracy]

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.

Re:Zen and the art of motorcycle maintenance.

[Mr. Slippery]

You know, every hacker should read "Zen and the Art of Motorcycle Maintenance".

Quality -- you know what it is, yet you don't know what it is. But that's self-contradictory. But some things are better than others, that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There's nothing to talk about. But if you can't say what Quality is, how do you know what it is, or how do you know that it even exists? If no one knows what it is, then for all practical purposes it doesn't exist at all. But for all practical purposes it really does exist. What else are the grades based on? Why else would people pay fortunes for some things and throw others in the trash pile? Obviously some things are better than others -- but what's the ``betterness''? -- So round and round you go, spinning mental wheels and nowhere finding anyplace to get traction. What the hell is Quality? What is it?

...

``Quality is shapeless, formless, indescribable. To see shapes and forms is to intellectualize. Quality is independent of any such shapes and forms. The names, the shapes and formswe give Quality depend only partly on the Quality. They also depend partly on the a priori images we have accumulated in our memory. We constantly seek to find, in the Quality event, analogues to our previous experiences. If we didn't we'd be unable to act. We build up our language in terms of these analogues. We build up our whole culture in terms of these analogues.''

The reason people see Quality differently, he said, is because they come to it with different sets of analogues. He gave linguistic examples, showing that to us the Hindi letters da, da, and dha all sound identical to us because we don't have analogues to them to sensitize us to their differences. Similarly, most Hindi-speaking people cannot distinguish between da and the because they are not so sensitized. It is not uncommon, he said, for Indian villagers to see ghosts. But they have a terrible time seeing the law of gravity.

This, he said, explains why a classful of freshman composition students arrives at similar ratings of Quality in the compositions. They all have relatively similar backgrounds and similar knowledge. But if a group of foreign students were brought in, or, say, medieval poems out of the range of class experience were brought in, then the students' ability to rank Quality would probably not correlate as well.

In a sense, he said, it's the student's choice of Quality that defines him. People differ about Quality, not because Quality is different, but because people are different in terms of experience. He speculated that if two people had identical a priori analogues they would see Quality identically every time. There was no way to test this, however, so it had to remain just speculation.

Tom Swiss | the infamous tms | http://www.infamous.net/

Re:measurement is the heart of science

[small_box_of_stuff]

But as you said, there arent enough hours in the day to do all the exta stuff. It costs extra to do this work, especially in the same time the work can be done with out it.

Forget the idea that science, good technology, or the right thing runs the world. Economics do. The almighty buck runs the show. Short sighted places will cut corners to make money, and long sighted ones will too, but to a lesser degree.

As things stand right now, Pharmaceutical companies and iron workers are forced to do what they do by rules and regulations imposed by the government, and a history of law suits, etc that were levied against the industries when they were younger and didnt play by the rules they do now. They wouldn't do it unless forced. It costs extra, alot extra, and unless everyone on the market place is forced to do the same thing, those that pay the extra amount to institute those safeguards are penalized by reduced market effectiveness, loss of competitive edge, and loss of profits. They are forced to charge more than their competitors, as they have to do much more work.

Asking companies to tie one hand behind their back in the fight for profits is ludicrious, and wont happen with out software development being turned into a regulated thing, like construction or the medical industry.

And while I cant say that this would be a bad thing, nor will I say its a good thing. You might not like it when the next version of office you buy costs 10K.

If companies got sued, fined, and otherwise penalized for not doing good work, they would be forced to do good work. but they aren't. They make things that are the least amount of work to get the job done, because that is the cheapest point they can shoot for. If every time Netscape crashed they got sued for breach of contract, there would be much more incentive for the company to try to do good work. As it is, there is really no significant results from doing bad work, as long as you pass a certain point of quality and dont turn away too many customers.

Unfortunately, neither good science, good technologies, nor good intentions rules the world. Economics is why good ideas dont go anywhere, and why mediocre ones excel.

-sbos

Problem is lack of trust

[sdirector]

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!

management or development methodologies?

[Cederic]

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

[rasilon]

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.