RUPS:
I couldn't agree more about outdated procedures slowing down the processes.
I have other observations and questions on the process...
The IS management structure seems EXTREMELY top heavy to me. How many levels are there above the actual developer who does the work and what value do they add?
You have other processes up front that the district developer doesn't have. You spend endless hours talking about what you are going to develop and producing documents.
I was told that the effort up front saves time later. I've never seen that. What % of a development budget is for actual development? When you subtract all the documents, testing, approvals, etc, etc, I'm betting a realtively small % is actually spent writing code???
In the district, code writing is a very high percent of the overall project.
I will bet you that if we got rid of the excess layers, and non value added work we could reduce IS cost for a system by 50%.
IS has some great people working in a poor process and the districts are paying the price...
P-Man
P-Man,
You are wise. It's good that there is someone on the forum interested in talking about process and not politics. Maybe a few people will read this discussion and consider updating an inefficient process they participate in regularly.
Programmers should be focused on programming. I buy into the theory of
"Effort up front can save time later" but it has to be the right effort by the right resource. Businiess Anaysts, QA Analysts, DBA, Server Admins, TSG, Network Admin, the cafeteria lady... everyone should have a role for specific tasks at a specific time.
When programmers spend too much time writing documents, sitting in review meetings and committees, sending out emails and updating timecards, the ability to write code goes down.
Very frustrating for the programmer who knows that he or she can accomplish more and very frustrating for the manager who has to share a project workplan with their boss at the next status meeting that shows slippage.
To be fair to the upper management, there are 4 things that are really causing confusion in managing IT
- Technology released today can be intimidating to non-techie types and unclear how to apply in a business environment. I find some of this web 2.0 / open source technology very difficult and I've been in IT for 25 years.
- Sarbanex-Oxley auditors, compliance auditors and the internal auditors who are as poking around in IS are always causing confusion as well. Each auditor can have their own requirements and it's often confusing understanding requirements vs. suggestions vs. violations.
- Competing technology stacks - UPS owns probably every piece of major software on the market. Which one should be used for the XYZ project? SQL Server, DB2, Oracle, Access, MySQL, etc.... Beats me but we own all of them and they all seem to work!
- Attempting to manage IT operations like package operations. It's a conflict between management style and employee style and a bad fit.
So to answer your question,
Question: How many levels are there above (and to the side of)
the actual developer who does the work and what value do they add?
Answer: Entirely too many and even though they believe they add value, they are often a distraction.
I say fix the process instead of trying to fix the people.
Go Brown!
rups