Layoffs in I.S.

[Motownpride]

Ramsey

She was our DBA in Morristown and we liked her. I heard from some guys in the cafeteria that you are joining us in Motown. Any truth ?

[ramsey500]

Originally Posted by Motownpride

Ramsey

She was our DBA in Morristown and we liked her. I heard from some guys in the cafeteria that you are joining us in Motown. Any truth ?

not that I am aware of----but I would welcome the change!

[Dfigtree]

Originally Posted by ramsey500

badmouthing the delicate flower?

who would dare to do that?

she will be king one day !

and I suppose you never worked for her either, have you?

I worked with people. If people were willing to work with me, I was willing to work with them. I never worked for anyone but I can say that when compared to her peers, the ones that I know of, she is the best of the bunch.

Over and out.

[rups]

Originally Posted by pretzel_man

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

1. 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.
2. 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.
3. 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!
4. 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

[07960]

Rumor is there is a 30% cut coming before year end in IS? There is a lot of space in the parking lot, consultants were given release dates, as were the PTer's. Staff appears stressed.

[pretzel_man]

Originally Posted by 07960

Rumor is there is a 30% cut coming before year end in IS? There is a lot of space in the parking lot, consultants were given release dates, as were the PTer's. Staff appears stressed.

I'm glad to see the cuts, as long as the message is to do more with less. That's the same message we have in the field.

My friends in IT say there are still no plans for layoffs of UPS employees.

I assume you are not an MIP participant. Non-union salary or hourly....

You mention working 12 hour days. On my assignments to IS (and I worked in NJ, Md, and Ky), I NEVER saw IS MIP people putting in hours like that. From my friends in IS, that is still true.

P-Man

[ISWarrior]

Then you never worked at / with the enterprise services like billing. But I do need to agree that there is dead wood (both consultants and MIP participants) that can go and I would not shed a tear. As for me, yes I am a MIP participant. Do I work more than 40 hrs a week? During certain phases of a project, yes when there are problems, yes. Do I do it more than 50% of the time NO. I have had a much as 70+ hour weeks (and that was only for two or three weeks in cricis mode), but I fail to see the shame in getting my job done in 40 hrs.

Originally Posted by pretzel_man

I'm glad to see the cuts, as long as the message is to do more with less. That's the same message we have in the field.

My friends in IT say there are still no plans for layoffs of UPS employees.

I assume you are not an MIP participant. Non-union salary or hourly....

You mention working 12 hour days. On my assignments to IS (and I worked in NJ, Md, and Ky), I NEVER saw IS MIP people putting in hours like that. From my friends in IS, that is still true.

P-Man

[pretzel_man]

Originally Posted by ISWarrior

Then you never worked at / with the enterprise services like billing. But I do need to agree that there is dead wood (both consultants and MIP participants) that can go and I would not shed a tear. As for me, yes I am a MIP participant. Do I work more than 40 hrs a week? During certain phases of a project, yes when there are problems, yes. Do I do it more than 50% of the time NO. I have had a much as 70+ hour weeks (and that was only for two or three weeks in cricis mode), but I fail to see the shame in getting my job done in 40 hrs.

First, no shame in getting work done in 40 hours. That's a good thing. In the original post I was responding to, the poster said he / she was working 12 hours every day. I've never seen that.

Second, on my assignments I didn't work in billing / finance, but I did work next to them. (At least I think that was the right group). At the time Stu S. was the division manager and he had an office in Ramsey. Worked on multiple projects with him and his user and IS group.

My biggest issue with IS is their process and top heavy structure. Many do not go the extra mile to service the business. I assume that you are NOT one of those I'm complaining about.

When I can see someone in the district create something for a tiny fraction of the cost of IS, something is wrong. What happens is the business is losing the benefit we need because IS cost is too high.

Change the process, reduce the number of management, give developers more empowerment, and get rid of the whiners. Do more with less and deliver more to the business.

P-Man

[upscorpis]

Originally Posted by pretzel_man

When I can see someone in the district create something for a tiny fraction of the cost of IS, something is wrong. What happens is the business is losing the benefit we need because IS cost is too high.

Change the process, reduce the number of management, give developers more empowerment, and get rid of the whiners. Do more with less and deliver more to the business.
P-Man

If you're stating that this is due purely to dead wood, then I respectfully disagree. The corporate IS team generally develops solutions that are meant for broad usage. The district "developer" is doing something for a much smaller and sometimes singular audience. The "abilities" of these types of development are quite different. Scalability, reliability, adaptability, flexibility, maintainability, reusability, supportability for large numbers of users and transactions are required attributes for customer facing, corporately developed applications. The district developed solutions generally focus on suitability to a narrow situation. These two types of applications are not the same and therefore cannot cost the same.

I understand what you're saying regarding the extra overhead. It certainly exists. However, to state this is the reason a district "developer" can do things more cheaply is a bit of a stretch to me.