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."
Managers are always doing some such silly stuff. Quality "training" and the like is real nice for getting a 'warm fuzzy' feeling that management has actually done something. In most cases that I have seen, training people who do not care results in money and time wasted. In IT, the needs of the company are often obscured by management who think IT is a department they can outsource. These types of managers are the same people who hold MBA's, yet do not have a business of THEIR OWN to practise upon. They grab a degree, and then think they are somehow 'better' because of the degree. IT functions can be simple or complex. Small business do not need Oracle or SAP, do not need large mainframes or the like. Training small business IT personnel can be a blessing or something else. It all depends upon the actual needs of a company. If most of the people in IT are simply software loading, password changing, wire wiggling tech types, why bother? Quality is determined rather quickly in such situations, it works or it doesn't. In larger businesses, the results are virtually identical, the system works, or it doesn't. All the training in 'quality' methodologies isn't worth spit unless the system(s) works. It must be noted that as mentioned in a previous post, many 'managers' are impressed by the level of 'training' the people in the shop have. Unfortunately, I know folks with all kinds of Certifications, and they are still clueless. I still have to help these "qualified" individuals out of simple mindless jams they find themselves in, on a daily basis. Quality is an atmosphere and excellence is an attitude. Training is no substitute.
The moral hazard of trying to idiot-proof the universe is to encourage the proliferation of idiots.
"My opinions are my own, and I've got *lots* of them!"
I have worked with and without ISO amd believe me there was a hell of a difference.
I can compare my work at Ford and HP.
In one case (Ford) the project was working well, everything was documented, if I needed to know how to do something (start a big calculation on a Cray or convert from one file format to another), I could just pick up the procedure and the doc. So ok, you loose time doing all the paperwork but believe, on big projects, you soon see the big advantage of doing so...
By HP it was just chaotic, no doc (or outdated ones). No coordination between projects... The number of times our program was breaking down because of changes brought into the input file after a request from another department. Even in the same development team, things got ugly sometimes because there was no real coordination... Of course all these problems could have been avoided just by beeing clever and taking some precautions but programmers are lazy and don't like extra constraints. So ISO (and others) is there to force them to.
If there are more than one person working on the project, then yes, ISO (and other time consuming and ressource waiting procedures) are a necessity!!!
Black holes occur when God divides by zero.
Most of the TQM stuff is a waste of time in the most literal sense --- paperwork is generated for the purpose of satisfying an audit and is never again revisited nor used by anyone. As a freelance contractor, I've seen that too many times in too many companies for this to be a one-off aberration.
Here's a quick recipe for quality in the workplace: Responsibility and Traceability. Give people full responsibility over a complete part or aspect of the product, and ensure that you can trace back to the party responsible at every stage. And make the responsibility stick, all the way up to the ultimate sanction of financial penalty or loss of position or employment.
People will do a good job when they have full responsibility over something, unlike when they are made to feel like an anonymous cog in a big machine. Give them that (and the authority that has to go with it) and you'll get quality, with minimal paperwork.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Not true... from above they can fire the "bad quality" and hire the "good quality".
:-)
Sure, they can fire the bad quality, but how exactly are they going to hire the good quality?
See, it's not that simple. Resumes do not give managers any insight into the quality of a person as this is not the same thing as skill set, and even worse, if managers practice a hire-and-fire policy in a scatter-gun attempt at finding a good set of people then the better ones will start to leave because of bad team feeling. No, it's not that simple. Giving people motivation is a better approach.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
We did the TQM thing as a govt contractor about 10 years ago. Good way to burn up half a day for a couple of weeks, was a change of pace if anything. In the end, we bench techs still did things as we did before because we didn't control the procedures anyway. If anybody actually DID want to alter a 'procedure' to improve the quality of our output (in this case 'work' was 90% attention to paperwork to document the 10% actual work done) it would've taken going over heads, pissing folks off, filling out forms 99-TQ/120-X in triplicate, a congressional appropriation, and in general being such a pain to everyone involved that the payoffs didn't warrant the effort.
In short, mgmt procedures just limit my freedom to innovate! See the movie 'Brazil'.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Quality Assurance is a process that makes the difference between M$'s security holes and a secure system.
Quality Assurance is a process that let you pick up a system and shake all the bugs out.
Quality Assurance is a process for building systems st that you maintain a knowledge base to identify ALL components of a system, ALL objects, ALL methods, ALL relationships, ALL functionality and completely cross-reference eveny meme in teh knowledge base.
Quality Assurance lets you deliver a system to your clients and live with it afterwards.
That said, most corporate QA efforts are poorly implemplemented and lacadaisically enforced retrofits. QA at start-ups are lousy and the products can't evolve and don't outlast the creation team.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
How often have you been asked to do something stupid to preserve an unrealistic schedule? Did it help (rhetorical question)?
Well-implemented methdologies can control management by making them follow the same rules the programmers do. Management and business owner expectations are based on defined processes and nobody entertains the notion that the project can be started without a spec and a plan.
Poorly implemented methodologies are used to control programmers while managers continue to do their counter-productive thing. If that is the case then the wrong people are being controlled and the methodology will not do any good.
Don't throw the baby out with the bathwater - methodologies can be very worthwhile if they are implemented well and followed consistently.
Not true... from above they can fire the "bad quality" and hire the "good quality".
These methodologies are the management equivalent of profiling and debugging for programmers. When you write code, you want to know how well it is performing, where the slow parts are, etc. Management methodologies are exactly this. Process management is a science, and it has rigorous steps. A good manager will understand these methodologies, so they can focus on the intent of them and leverage trusted techniques. Of course, a manager who has only had a 2 week course in various methodologies is likely to mess them up-- just like an inexperienced programmer who has been told "use this profiler" and has never seen such a tool before. -m
The problem isn't with the various methodologies. Rather, the problem is with the implementation of these methodologies. Just like anything else in the work environment, you can force your employees to learn these practices, but if they don't actually follow them then of course the results will be poor. The root of the problem is generally something much greater than the programming methodology though; plain poor upper-management comes to mind. If you look at software shops that people do respect(i.e. IBM, NASA, etc.), you'll find that these practices do work but they work because these organizations already have a good infratructure in place. These shops also realize that these practices aren't magic bullets unlike some of the smaller shops. Sorry for the rambling.
Sources of Power: How People Make Decisions, Alan Klein, MIT Press.
This is not a book about IT methodologies, but it it gets to the heart of the problem I have with most management and system analytic methodolgies -- they are based on a flawed model of how human beings handle information and make decisions.
The standard cognitive model, whether explicitly held or not, that underpins most "methodologies" I have seen is "rationalistic decision making". This model goes something like so (more or less from memory):
(1) Define the problem.
(2) Generate options.
(3) Create framework of metrics for evaluating options.
(4) Apply metrics to options and compare.
(5) Select optimal approach.
While this methodology does occur in the wild, if you will, it turns out that it occurs exclusively among decision makers who are novices in the problem domain. Field studies show (contrary to expectations) that expert decision makers almost never work this way, and case studies show that in complex environments with many unknown factors, changing goals, and time restrictions, attempts to apply this model are unsatisfactory.
In the real world, highly expert decision makers work something like this (this is simplified and reconstructed from memory):
(1) Evaluate situation
(2) Take the first approach that comes to mind.
(3) Mentally reherse approach. If problems refine or go to 2.
(4) Execute plan and evaluate as you go. If things are not going as expected go back to 1 or 2.
The key word here is "satisficing" -- instead of searching for optimal approaches, the expert goes with the first approach that comes to mind, mentally rehearses it, executes it, and possibly reevaluates the goals. This is sometimes called Naturalistic Decision Making or NDM.
Peole use both kinds of approaches, but NDM works better than RDM in many situations. First, there is the problem of where the good options come from in the first place. NDM plays to human cognitive strengths (imagination and role playing) and avoids human weaknesses (keeping two or more things in mind at once). It fits the real world scenario where the decision making process must be non-linear -- goals may shift during execution as new data is received. Example: the fire department goes into a burning building with the plan to get above the fire and contain it, but then discovers the blaze is larger and shifts to search and rescue then keeping the fire from spreading to nearby buildings. Finally, NDM results in faster execution than RDM; this fits Peter Drucker's criterion for management excellence -- a "bias for action". In NDM you get right into planning action, and if you can't make it work (mentally or in execution) you abandon the approach and build a better one.
I think the NDM/RDM dichotomy underlies a lot of problems between geeks and managers. RDM is an academic model, and geeks, whatever there relationship to their schools and teachers, are incredibly adept at absorbing this kind of stuff. Secondly, RDM is hard precisely in ways that geeks excel over the general population -- abstraction, numerical manipulation, handling large amounts of analytical data.
In any case, this book crystalized the problem I have with IT and analytic methodologies in general, which is that they assume a problem of optimization rather than one of quick and satisfactory execution. It also explains why people again and again invent methodologies that work for them but subsequently fail to be the "answer" (although in general I think we are getting a little smarter). The missing ingredient is the experience and common sense of the successful team's members.
I think the implication of this is that IT activity should be based on developing flexible and repurposeable systems, rather than optimally solving a single goal or a bounded set of goals. I've been out of the IT world for six or seven years, but the impression I get is that the major trends in IT have been towards repurposing of data and away from complex schemes to solve bounded problem sets.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
OK this is a little OT, but here goes.
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.
Well, writing documentation, drawing diagrams, and tracking time aren't demoralizing in themselves. It's doing work that, on one hand, has no value to the company, and on the other hand can be used as a stick to beat you that is demoralizing.
I've been unfortunate to have had a high enough position that I got to participate in the sadistic excercise called "mission statement preparation". In fact, one company that I worked for was so enamored of this everybody got to spend some time in flip chart hell, because every department and work group needs to have its own "mission".
In my opinion there should be a simple social contract between higher levels and lower levels in an organization: the higher up provides leadership and the lower down provides expertise. This is a position of parity, with each party providing and receiving something valuable and which makes accountability, in both directions, a possibility. The problem is when the management abdicate the leadership role (which they are probably not up to) to a committee with a flip chart.
Speaking as a dyed in the wool left leaning liberal large D Democrat, I have to say that managers who share my political stripe are the worst offenders. On the face of it, it is all sooo egalitarian -- except that it's not. It's more a fig leaf for higher ups evading their responsiblity to do meaningful work for the company. The big cheese still gets all of his whims catered to, and is free to ignore and interpret the mission any way he pleases. Sometimes it smacks of being in a communist reeducation camp.
Getting back to methodologies, if you are cast adrift with no leadership or idea of what needs to be accomplished, no methodology is going to save you.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
We call it CYA.
Producing a libraries's worth of unusable documentation just because it fulfils a line of a checklist is not quality, only the shadow thereof.
No, I think anyone with a real CS background understands the need for the procedure. We just want procedures that help, rather than hinder, quality results. Faddish "IT" methodologies (indeed, pretty much anything with "IT" in the name) are based on a poor understanding of quality and creativity.Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Actually the problem with ISO 9000 (or QS 9000, or similar) in my experience IS implementation. For a known product proper documentation ensures not only that you produce it correctly, but you are also checking all the important areas. Improperly implemented it is just a paperwork mess.
I once saw a large crate outside the building where I were that said "WASTE MANAGEMENT SERVICES".
I thought to myself... "Waste Management... perhaps I should give these guys a call."
-=-
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
You're damned right about the "government mandate" on ISO - here in Australia it's the same. In some cases you cannot even tender for work if you're not ISO certified (or, perhaps, just "certified" in general :)
:)
:)
It always used to crack me up that they wanted ISO certification for quality assurance but ISO-9000 never addressed quality! It ensured that you had a process and that it was monitored, but it never did anything to improve quality. You could have a process producing a large number of defects but, if it was documented & repeatable, it could get certified.
At least they've recently addressed this with an update to include quality. Pity it was never there to begin with
As to vendors pushing their way as a "one size fits all" - funny that. Vendors are always doing that with whatever is in vogue (BPR, TQM, CMM, ISO, CRM, ERP - whatever
I left my body to science, but I'm afraid they've turned it down...
There's a lot of "Methodologies are great" vs "Methodologies suck" view points out there (mostly the latter here on /. :) As has been noted in previous posts under this thread, most of the problems relate to people seeking a "Silver Bullet" solution and mindlessly applying a methodology that worked elsewhere in the inane hope that it will work here. This is similar to checking out your competition and determining that they are better than you because all their people have blonde hair, blue eyes and use brand new shiny PC's.
:) and now moved into the Analyst / Project Manager / CEO world, I'm fighting all the time against PHB's who want to just drop methodologies into development teams and walk away. I've implemented existing methodologies, I've consulted on fixing the mess from a failed implementation (not one of my own, thanks :) and I've even hacked together some methodologies for a few clients.
t -here).
I recently heard the following phrase:
"You can lead a person to a methodology but you cannot make them think!"
Unfortunately, this is all too true. I've even encountered one group who probably couldn't get Extreme Programming right!
Having come from the programmer world (yes, I was a serious code-cowboy - I've still got the spurs to proove it
The secret is to think when assessing each situation. In some situations, I throw the book away and put together a bare-bones, absolute minimum repeatable process for a small development team. This lets them put some level of control & prediction into their work while still staying loose, having fun, focusing on the important stuff and keeping the primadonnas happy. In other situations, I pull out the CMM/ISO/(insert-heaveyweight-methodology-here), start tailoring it and introducing it slowly.
It all depends on the environment, the team and the goals. If you want to do is ensure that there's a modicum of control and that programmers aren't being dragged about from target to target, go with a light-weight system. If you are developing "life-threatening" systems such as nuclear reactors or air traffic control, damn straight you do it by the numbers with full control, reviews, checkpoints and such.
In all cases, you must continue to think. Too often someone sees a methodology as a burger-flipping process (eg: plug in some staff, follow the steps and out comes a golden solution). This is complete crap and a sure-fire disaster. At all times you have to ensure everyone in the team (from top to bottom) is turned on, tuned in and thinking. If anyone tunes out and believes they can just follow the steps without thinking for themselves, fire their ass!
Many programmers say methodologies get in the way and stop them working. I say that a good methodology (eg: one that's right for the team, the task(s) and the goal(s)) will let the programmer work in heaven (eg: little to no interruptions, focussed direction, constructive reviews and awareness of the big picture).
Like anything else, methodologies do work when they're used as yet one more tool in the hands of turned on, thinking people. Like anything else, if you just drop it in and hope it works, you're a fuckwit/dickhead/(insert-national-phrase-for-idio
I left my body to science, but I'm afraid they've turned it down...
why don't you try reading the book (online version). if you are interested in what he is talking about.
---
DO NOT DISTURB THE SE
That's not to say that some process isn't a good thing, and unless your team of programmers is absolutely excellent, that process will have to be mandated from above. Without some order, your project will slip into chaos, and I've seen that happen firsthand. But process is only one part of a much larger whole, and many companies on the bandwagon treat it as if it's everything.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Here are some examples. Note that it's not just the competency of management that counts, but also the organizational structure that makes quality a priority. All too often quality just gets lip service, rather than full-scale support. Part of that, of course, could the scale of the IS department. Smaller groups don't necessarily have the resources to implement a true QA process. I was part of an IS shop that grew from 5 to 40 programmers over the course of a few years, and the need for a systematic methodology went up just as quickly as the number of programmers did...
Stop by my site where I write about ERP systems & more
Smaller projects can't handle the overhead. With eight or 10 people you can't spend time on non-critical activities and documentation. Communication within the team is easy so you don't need the support.
However, almost all teams need some kind of roadmap. Having a documented process improves your chances of success because you now have a "checklist" of activities. In my experience, projects fail not becase of insufficient skill but because things don't get done. Process documentation helps ensure that things get done, and get done correctly. I like to think of them as design patters for project success.
Neutron
I get my kicks above the
Whilst tortured syntax and archaic word forms may be popular amongst those whom you are acquainted with, they don't make you sound smarter to someone who knows the languague.
I don't mean to belittle you so much as to make a point that it's not nice to criticize, and incidentally, that the real problem with IT management is that people not qualified to judge the quality of a job should not be doing so.
And now that I've warmed up to a cold topic, allow me expand on the incidental:
You make a good point about knocking methodologies that you probably don't understand and it is true that many programmers don't fully understand the needs of management to measure, direct, and document their work; but the greater imbalance is that management, more than ever, understands less about the work they presume to direct. In order to improve the quality of programming (or construction, or medicine) you must understand the process. The problem people have with management solutions is that they are getting furhter from solving the problem and more towards satisfying management for managements sake (job security.)
Managers who take classes in management are not qualified to judge the quality of computer programmers (steel workers, etc.) If you want management to lead effectively, they must be competent in the field they work in. It is pretty easy for an experienced programmer to tell if someone is serving them shit in a job interview or checks in sloppy code.
Now, not all experienced programmers are willing to stop doing what they love to manage. And God knows they aren't all able. And of course, there is the shortage of experienced programmers. But the truth is, they aren't encouraged to. Management hires from within. That is, managers hire MBAs over experienced programmers for management positions. And they contract with Management Consultants, rather than listen to their programmers.
I've worked with numerous managers and project managers. The greatest blessing a developer can get is the support of a *good* manager. Good, experienced managers don't need methologies any more than a good programmer needs flow charts.
A lousy manager, OTOH is a danger to any project as well as your own sanity.
The best way to work with an inexperienced manager is to follow some methology . Most of them merely states the obvious, and serves as a check list.
Sure it is a pain in the behind to use precious time for paperwork, instead of "real" work. But believe me. The pain that comes from a manager who *should* have used a methology, but played by ear instead is worse.
And if it goes really bad. The best way to show your CEO that the reason the project went sour was your clueless manager, not you is to be able to refer to some buzzword-filled methology, not "1 4M 1337 H4x0r, M4n463M3N7 5uX"
All opinions are my own - until criticized
Hear, hear!
I was one of the lucky and very rare people who got onto a project where TQ was: (1) taught, (2) implemented, and (3) given the time and support required for success.
Even in my own organization, nearly everyone got #1 and #2, but #3 was neglected. With us (some kind of radical fluke situation, I'm now convinced), we saw all the wonderful performance gains and productivity increases that TQ promised. We also saw the initial drop in productivity while we got into the method. It was during that time that every other project I'm familiar with got shut down. Some of these methodologies do work.
Ultimately, my conclusion was that various methods work when they are committed to and given time to work. They "get everybody on the same page." Oftentimes, they provide a common frame of reference and language for describing problems that make achieving goals easy once everyone knows the language and uses it religiously! Getting to that point, though, takes time. And time is what most IT shops just don't have.
These systems exist for many of the same reasons we have our jargon. By adopting a common language, we can communicate quickly with our peers. That's valuable. How would you like to be forced to explain every programming problem in language my completely non-technical mother could understand? It could be done, but it wouldn't be worth the effort. These methodologies accomplish the same thing with management problems as our tech jargon gives us with tech problems - they give everyone a common language and base of understanding on which successful communication can be built.
But half-assed implementations are doomed to failure. And nearly everything gets done half-assed these days. :-(
I belong to a company which believes in ISO 9001 and CMM. It is one of the big Indian shops with most of its offshore centers certified under both these management / quality methods. I've personally been involved with both these activities for a long time as a Project Leader and later as a Project Manager, and I found that there are both good and bad aspects of these certifications. The methods are extermely useful in a large (or very large, say 20,000 people) company, with a high turnover rate at it is in this industry. Unless you have properly planned or written down things methodically, you're going to die when your key designer leaves the job. In big projects (with 50 - 100 people), this planning is essential. And these management methods enforce that planning and documentation. And if you are a big organization, this also enforces code and concept reuse. This really increases productivity, which I can personally vouch for. So that is the reason the management wants to implement these methods. However, there is a trap in this. If not properly implemented, this can cause severe problems. People may stop being productive or may leave. But on a whole, I found this to a useful thing. You can compare it with a knife - it is quite useful, but if wrongly used, can cause mayhem.
Through all the companies I've been in, in several departments and several positions, I've consistantly seen one thing that would improve things dramatically: Accountability. The consistant and regular application of accountability to anything you do as part of that company, weather you're a grunt or a VP. If you're a QA tech, say, and you sign off that, say, the COM loading interface of your product works, and it ships, and it turns out not to work, in trivial and stupid ways, then you should be held accountable. Even if it's just a weekly 'wall of shame' intranet site for your co-workers to look at, fine. Similarly, if a VP makes an obviously stupid decision, ignoring the advise of everybody who knows better, when the shit hits the fan, it should be made known. Conversely, success reports need to go out on a regular and consistant basis. Carrot and stick.
Vintage computer games and RPG books available. Email me if you're interested.
I hate the term.... People cannot be "managed" (with the implication being that you are forcing them to do something they would not otherwise do). They can be led....inspired...motivated.... At least if you want long term, productive teams this is the case. Funny thought, coming from a CTO that supposedly has many "management" responsibilities. One poster has it right....management is the panacea for those that are too afraid to show some leadership and trust in their team members.
Chaeron Corporation
I can't think of one non trivial piece of software that I use today that was created by a "rogue programmer in the basement". It's all simply too big and complex for one person to write on their own. Even successful Open Source projects follow a methodology (see Eric Raymond's "The Cathedral and the Bazaar").
Good methodologies are designed to protect the project from idiots of all types. These include idiot users, idiot customers, idiot programmers, idiot designers and, most importantly, idiot managers. Some of them are (in my experience in production software environments) more successful than others.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
If you are a middle manager, you success might be measured in a plain costs vs revenues scale. This method, however, lacks any strategic depth - for such a manager, specialy given the current job mobility, it makes more sense to generate short-term sucesses by sacrificing long-term sucess (for example, by burning out your best programmers to finish some project in an impossible deadline).
Also any type of investment that will hit the bottom line but only yield results on the medium/long-term will not be made.
Oops - time's up - gotta go!!!
Before you know it you don't have your current procedures documented, you have something far more complex, but then you have to follow it to conform. This is then followed by tears and recriminations.
No methodology is a substitute for your manager using his ears and brain together (at the same time - yes it can be done!:)
Methodologies are a toolkit. It's all about using the right tools at the right time. Use too many and you're going to irritate the entire team as well as waste time. The real skill (and yes it is a skill) lies in knowing how to balance this.
Methodologies are not a religion. Adhering blindly to any doctrine rarely makes sense, unless your project has come completely off the rails and it needs some discipline to bring it back in to shape. I've seen this happen and the managers who really know what they're doing can really make it work.
Methodologies are common language. If you understand the Prince 2 terminology for example, anyone conversant in it will be able to interpret project documentation quite easily. Often it's a problem if two or more organisations working on the same project all use different terminology.
If your organisation has invested in a methodology, chances are it's been looking for ways to improve how it does things. This is good, as long as enough people buy in to the process. It's also vital that it is sustained by those involved. Often it requires a iron leader to enforce this. At my previous employer, the Year 2000 program manager was hard on the team about following the processes, but in the end it all came together and all of the projects were successful.
Yes, procedure is often the enemy of creativity. It's all about achieving the right balance between the two and if you're pissed at procedures perhaps your boss has got the mix wrong.
Rob.
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.
Perhaps, but adhering to good standards and writing clear and concise code should be drummed into trainee programmers until it becomes second nature. Then maintenance of old code becomes less of a trial because it has been written properly. Code reviews should be done fairly regularly for new coders to ensure that they are doing the work correctly. This saves a fortune in the short-to-medium term, never mind the long-term, as anyone coming to modify this code doesn't have to spend loads of time figuring out an appalling hack. When IT people realise this, our job will become a great deal easier.
Plan your work and work your plan.
The most conscise statement of project management I have ever seen is codified in the Jaycees' "Chairman's Planning Guide (CPG)".
The sections of this form to be filled out are:
Planning
Implementation and Evaluation
All methodolgies are just elaborations of the above.
Don't knock "PHB's" too hard - if you're ever worth your weight in salt, one day you'll be one.
There are a hell of a lot of nonprogrammers out there with good ideas, some of which you wouldn't come across your self unless you had their perspective. Don't knock it, use it - incorporate the good ideas wherever you find them, regardless of the background of the person offering them.
That's not the same as "getting some Quality" which is what all these Quality systems imply.
Management often think they can just buy "Quality" and invest in these systems. However, you can't just buy "Quality", you have to *believe* in it. You can spend as many millions as you like on consultants and quality systems but that doesn't mean that you have a better business or better products.
Government of the people, by corporate executives, for corporate profits.
Quality does *not* start at the top of the heirarchy, what utter crap.
Quality is up to the individual. Either the individuals concerned *believe* in doing high quality work or they don't give a shit. If they don't care then there isn't a quality system in the world which will make a difference.
Government of the people, by corporate executives, for corporate profits.
'Quality' cannot be enforced from above. It's that simple.
So, saying we need to get some Quality is stupid and the people (management) who think that they can get some 'Quality' are stupid.
Government of the people, by corporate executives, for corporate profits.
I agree that it is reasonable for management to expect good quality work from employees but you can't buy Quality.
The problems is that most management think that they can simply buy one of these quality systems, hire a few consultants and they magically have "Quality".
Not the case and simply trying to get quality by implementing a quality system will not give you a quality business, quality management or quality products.
Quality is a belief, *not* a methodology.
Government of the people, by corporate executives, for corporate profits.
Science requires definition. You go and define what quality is before you try to measure it.
Until you can define for me what quality is and how to measure it, don't try to tell me that Quality systems measure quality.
Government of the people, by corporate executives, for corporate profits.
If the company you work in have such methodologies and documentation crap, just tell them that you don't like it and that it's not in your best interest to work in such a company. Trust me it's not a good idea to waste your time working at that kind of job.
That's what I did and they listened.
As with real diets, any real effort to develop a Management Methodology, whether adopted from the outside or developed internally, will have a positive effect. What won't work are fads and half-assed implementation. The latter explains most of the failures in Management Methodology. For the most part, poor managers start to look at these Methodologies to explain failures not prevent them.
This is not the way to build a lasting empire.
The most effective methodology that I've seen in IT, and I've worked for companies of a hundred or so and for a few that are over ten thousand, is to keep teams small, and to build those teams of people who work together well and get things done. It's easier to teach someone the required skills than to teach them to cooperate happily. And when someone isn't working out, don't give second chances. Give them the axe when the trouble starts. If that policy is presented clearly and up front, there are no surprises when the axe falls.
Much of the inefficiency in companies today, regarding IT or otherwise, is because of tip-toeing around petty office personality problems or silly ego pandering. Trying to keep people happy takes time and energy that should go into getting the work done. Surround yourself with people who get things done and without hassle, send the rest packing.
- Sig this!
A full implementation of ISO 9000 would be ridiculous for our 6 member office. However, some ideas from ISO are helpful. For example, ISO requires version controlled documentation for every business procedure. We wouldn't have any business procedures if we tried to do this for everything since most of the stuff we do is constantly changing in response to changing technology.
However, there are a small number of less frequent and less high tech activities such as shipping UPS packages to clients that benefit from documentation. It saves running around asking where the various supplies, price charts, etc are.
My observation is that most Management Methodologies are designed for large corporations. Small businesses can benefit by applying principles from the large scale version to create a tailored "Lite" version. Unfortunately, such "Lite" versions do not get you a certificate. (Or maybe that's not so unfortunate :-) Furthermore, small businesses cannot afford the consultant based implementation approach.
In conclusion, vendors of methodologies are missing a large market. Small businesses need streamlined, "Lite" versions which do not require an expensive consultant. There should be certification programs designed for these requirements.
I lived through years of being force fed TQL, the US Navy's version of Deming's Total Quality Management. Although Deming had a lot of good points, I couldn't help but feel that we (as an organization) got entirely too wrapped around the axle with the methodology and lost track of the objectives.
A fundamental point of Deming involves understanding the process being managed, knowing the components of the process, measuring the inputs to the process and thereby knowing what you can expect as a result of the process. The key point to all of this that seems to escape many people is the idea that you're actually supposed to know what you're doing.
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.
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.