When Government runs IT
This is what happens. Do I fault the IT guys? Nope. I've been in IT for 20 years and the overwhelming cause of IT project failure is mis-management and scope-creep. And you get them BOTH when you get elected officials involved.
Those who gravitate to management tend to be what is known in organizational management circles as "drivers". They are the "let's just get it done" people. Those who gravitate to IT are typically analyticals or the "let's do it _right_" people. These two clash. Drivers are used to being able to just "wing it" and bull their way through objections and obstacles - which is how they normally end up in management. That technique just doesn't work at all in IT and drivers ignore those in IT who try to tell them it doesn't work that way because they are used to their techniques getting them success.
Here are the keys to a successful IT project (so far as I can see).
#1. Realize that every IT project is doing something you have never done before. Make wide accommodations for what you just don't know going in. This drives managers nuts who want "deliverable" dates. Tough. A = A.
#2. IT has enough trouble just trying to get done what is in the project scope while trying to deal with the unknowns that pop up. The best way to crash a project is to ask for changes partway through. Say NO to scope creep! Iterative development and prototyping can help identify problems earlier, but you have to resist the urge to keep adding requirements unless you are also willing to push out the completion date - even for so-called "trivial" changes.
#3. Trust your IT people and get out of their way. We mock helicopter parenting, but helicopter managing is WAY worse. It's okay to have a periodic status report meeting and in fact these are encouraged so everyone can be aware of issues as they come up.
#4. Remember that every distraction you involve them in means 2x the time they lose addressing the project. Task switching has enormous costs. The worst thing you can do is interrupt them for something trivial while they are at their desks. Send them an email or catch them just after a meeting instead.
#5. Be nice. Bring donuts or bagels every now and then. IT is the most under-appreciated yet vital part of any modern organization. They get crap from you every day for what isn't working perfectly (for things that are usually your fault - not theirs). Recognize them OFTEN when things are going well, because that didn't happen by accident!
Normally I agree with your posts, but this one I disagree with. I am a 'get it done' person. What I know about IT is not large: I have done a little programming and I can do reasonable computer related tasks.
My job is frequently to kick the butts of the IT people who get into a loop of 'doing it so right' that they never accomplish anything at all. After months of nothing to show for what they have done, I come in and start spouting 'do in NOW' plans - this generally results in something effective being turned out that is more developed than my 'NOW' plan but which is functional instead of iteratively impotent.
Your management plan far underestimates the degree to which people in general, and in IT in particular (which - as you point out - is a self-selecting minority) are totally incapable of producing on their own. I really wish this were different, but I have repeatedly tried to let people alone and not nag them...and then nothing has happened; sometimes, for years. There are a large number of superbly intelligent and entirely unmotivated people in this world. Helicopter management? I want one!
Jan
You make an excellent point on the "doing it so right" aspect and one I heartily agree with. Analyticals will default to 100% correct, so care is needed to point out and explicitly agree upon solutions that will get a functional - though less than perfect - outcome. Management in these situations can be of infinite help here simply by telling IT that they are perfectly happy with an 80% job and accept the inevitable bugs, etc. that will come as a result. (Haven't met too many managers willing to do that, ironically enough. LOVED the ones who would!)
You may or may not have noticed that IT by nature is a risk-averse environment. Why? We never get complimented when things are working well, but there are plenty of screams when things break! So we are justifiably hesitant to violate the age-old rule "if it ain't broke, don't fix it." There are also many aspects of IT where we act as gatekeepers. DBA's are notorious because they are tasked with ensuring data integrity, which simply demands 100% accuracy and nothing less. Network Admins are always trying to ward off the black hats out to steal corporate data and even personal identities. And we tend to take those responsibilities rather seriously even when it means protecting people against themselves.
I would also ask you to consider how many people in your organization are on-call 24/7: who frequently work on holidays doing systems upgrades, patches, and other maintenance while everyone else is kicking back? I know few people in IT who actually get real holidays with no cell phone and no worries. Additionally, how many of your IT folks also act as the bosses' personal IT call centers for home networks, PC issues, etc.? Pretty much every one I've ever worked with. And do they get any kind of additional pay for these services - which would normally bill for $125/hr?
We are in large part a product of the environment and ideals fostered by management. If you are frustrated with the seeming inaction of your IT department, you would to well to recognize that you - as a manager - control in large part how IT deals with change by virtue of your reactions when things break! If you want to encourage change in your IT department, you have to encourage some risk-taking, which means tolerating the inevitable hiccups and downtime! Omelettes and all that...
"Your management plan far underestimates the degree to which people in general, and in IT in particular ... are totally incapable of producing on their own."
Perhaps. Perhaps not. When one takes into account all of the business activity simply _enabled_ by IT and that it takes active management for this enablement, I don't believe I underestimate at all. Can you survive a day without email? Wi-fi? Your business applications? How much money do you lose when the power goes out and all those automated processes are down?
We're not perfect. But give us a little credit. Please?
Is that OK?
But I am also quite aware that your well-phrased second paragraph seems the rule. Perhaps this is not entirely due to being risk-adverse, but also due to the fact that programmers think that if only they mull stuff over 'a little while longer' they can make it even better.
Wm is right: I worked 17 years on graveyard shift in a hospital laboratory. You had to do things perfectly and immediately. That is not possible...so what you really had to do is do things as well as you could in a short enough time to help the patient who was bleeding out or turning blue in ER. I am very accustomed to making decisions that involve the phrase 'good enough'. It is no use turning out a perfectly complete Chem panel after the patient is dead if instead you can get just the Electrolytes to the doctor in time to keep the patient alive.
Jan
http://www.cio.com/article/2920900/agile...
Jan is probably talking more about software development than traditional IT, we are a small software house and while we do traditional IT, much of what we deal with is actually development and the perfect is often the enemy of the good.
One of the biggest threats we have when we get bogged down in analysis-paralysis is that Jan will 'help' us. The threat alone is often enough to get someone to pick one of the options they are contemplating and go with it.
Just another way of getting the job done. You can read more about it in my book "In Pursuit of Manufacturing Excellence-The Signicast Story". It is in the Marketplace.