General discussion

Locked

How long before change

By The Young One ·
A hypothetical...

Your old manager has just reduced their hours significantly and you have got a new manager in to take up the majority of their weekday hours...

Everyone likes to make changes, make their mark and so on....but how long should a person bite the bullet and stay with the way things are before jumping in with both feet and turning the tables upside down?

Talking to someone not in IT, we came to a conclusion that newbies really need to know a system (working like a well oiled machine) inside out before deciding to change how it works.

Anyone else ever seen this sort of thing happen?

This conversation is currently closed to new comments.

16 total posts (Page 1 of 2)   01 | 02   Next
| Thread display: Collapse - | Expand +

All Comments

Collapse -

If it is working

by dbgirl In reply to How long before change

If the current system is working "like a well oiled machine", then don't be in too much of a hurry to change things. If you are looking to make your mark, then do what you can to make sure your ideas will do more good than harm before changing anything. Change simply for the sake of change isn't a good idea.

There is no rule about how long to wait before making changes. It depends on the needs of the organization. If what is being done works well, then what's the rush to change? If what is being done doesn't work, then do what you can, as quickly as possible, to bring about change.

Collapse -

Well Said

by Oldefar In reply to If it is working
Collapse -

Change is good, but it can cost you

by nexed In reply to How long before change

Whenever I start a new job, I always end up looking at ways to improving the existing tasks. But before I go and make changes (other than cleaning up the mess I was left with) I would research the change, get/make/compile supporting documentation showing that such a change is for the good, and then get approval from someone higher. There is no timeline for any of this; all depends on how confident you are on making the change and how it will improve the network.

Another thing to help is, talk to your fellow co-workers that could be affected by it, if they seem enthusiastic, you will probably have their support. If they seem reluctant, try rethinking the idea, or figure out why they started to run for the hills.

Collapse -

Change should fix something

by Steve@SMC In reply to Change is good, but it ca ...

Change is not good or bad. Where most IT people make a mistake is listening to all the "expects" and vendors' sales pitches that a change (code word for spending a lot of money) will improve their ROI and performance. Before considering to make any change, whether it be hardware/software or personnel, one must ask the question "What is broke?" Then consider this reality "The business is not there to support IT. IT is there to support the business!

Collapse -

Bravo!

by RknRlKid In reply to Change should fix somethi ...

Steve, you hit the nail on the head! Change should be to improve overall performance.

I keep thinking about the MultiMate/WordPerfect/Word wars when I was in the Army. What a waste of time and productivity. After spending thousands of dollars and man-hours training support staff on MultiMate as a "standardized" word processor, someone got the brilliant idea to change to WordPerfect. Thousands of hours and dollars of productivity were lost as everyone learned new software. Then, Windows 3.1 came out, and everyone had to learn Microsoft Word for Windows, because it "looked better." (No kidding. Appearance (i.e., fancy fonts) was more important than being productive.) So more hours and money were lost trying to get as proficient in Word as they were in WordPerfect. Then, Windows 95 came out....

It goes on and on. The latest and greatest isn't necessarily the best. Changing software actually makes the staff less productive, not more, and creates alot of stress on those you support. So chose wisely, based on business needs, not sales pitch.

Collapse -

Change

by timwalsh In reply to How long before change

Whether a newbie or not, one of the traits of a GOOD manager/leader is to do nothing but initially observe to see how things operate when moving into a new position.

Even experienced (yet cluless) managers have been known to make changes only for the sake of making changes (usually with detrimental effects).

Even if a problem is known to exist, unless time is taken to discover the true cause, any changes made are really only treating the symptoms.

How long? There is no set time period. It is usually based on the experiences of the manager in question, as well as how obvious the true cause of a problem may be.

Realize also that problems to be resolved need not be the sole reason for making a change. Things may be working smoothly now. But maybe the new manager sees a mor efficient way of doing things, thus causing a change to occur.

Usually immediate changes (unless there are obvious reasons for making the changes) are a sign of either an inexperienced manager/leader, or one with a big ego.

Collapse -

Policies, procedures, and plans

by road-dog In reply to How long before change

A new Manager should review the organization and contrast its current condition with what he views it to be to support long term goals. That is where his "stamp" could be made on the organization in a lasting and meaningful way. Change for the sake of change offers little in the way of legacy, as minor and superficial changes are easily undone by one's successors.

If the Manager really wants a footprint, he should shape the plan and then move the organization in that direction. The better the plan in terms of the company's business goals and his success in carrying it out, the better the legacy. That is long lasting and memorable, a bold and noble goal and success in attaining it...

Collapse -

Find out first

by Deadly Ernest In reply to How long before change

When I have taken over responsibility for a new area or activity the first thing I do is go around asking everyone what they do, how they do it, why they do it, and who they do it for. I also ask management and clients what they expect the area to be doing.

From this you develop a list of expected outcomes, the anticipated standards and the activities being done to meet those outcomes and standards.

You then chart the activities against the outcomes and the standards and determine if they are all still needed and if they are all still needed to that standard. Having established your activity base you then list the various resources being used to perfomr the activities. Then work with the staff to establish if they are the right resources to do those tasks and see if things can be done more efficiently or more effectively. Inevitably you will identify many activities that are no longer needed and can be safely dropped without harm.

When you have done all this you know what you are supposed to be doing, how it is done and what is used in doing it. Thus you can now make intelligent decisions about how you make the best use of your people and resources.

NB just about every worker knows a better way of doing their own job, so ask them, then examin how that affects others BEFORE you make any changes.

One place I worked at I had the people stop doing 132 tasks, 25% of the work, as we could not identify who they were being done for or why. In 6 years we only got complaints about 3 tasks. this made a lot of time and money available for what we were being paid to deliver.

Collapse -

This makes total sense

by RknRlKid In reply to Find out first

This post has some classic examples of why people should ask why sometimes. Change for the sake of change is disruptive; change for improvement in effectiveness is beneficial.

If a task has no purpose, then it should be eliminated. I think back to my Army days and LOTS of bad practices. Just because "its always been done that way" is not a reason to continue that way. And conversely, making changes to "make one's mark in the organization" is counterproductive. In my experience, "making changes to make one's mark" = "showboating so I can get seen and promoted." Those type of changes causes negative turbulence in the organization.

Collapse -

if it aint broke dont fix it, old time

by Oz_Media In reply to How long before change

The favorite phrase of those left behind is "If it ain't broke don't fix it". In many cases this stands true but ut many cases the people don't realize it's broken unless seeing how it COULD work.
Lets take VoIP for example. Many companies wont upgrade to VoIP because "if it aint broke..." but, if you competitors are using VoIP to incerase their service, lower their operating costs and improve customer satisfaction is that not the same as YOUR system being broken?
Too many peolpe use the old adage as an excuse to not spend money on improvements to thier company.
If these people knew how much better off they'd be with new technology, they would see it in a different light.

In MOST cases technology improves how efficiently companies conduct business, in turn saving them time and money (Windows upgrades excluded).

If the company's IT staff are on the ball, they will constantly be upgrading and improving the way the company does business, is this not the responsibility of IT? An upgrade is useful if the benfit is realized, I see many companies installing systems that are fantastic at improving how they do business but then they use only part of the package and don't get to benefit from all the software improvvements. If companies learn to use programs in thier entirety, they will gain better benefit and realize the improvements made.

If a new manager has new ideas, let him at it. If it all costs the companmy money and causes headaches for the users, he won't be managing for long. Let him do it, sink or swim.

Back to IT Employment Forum
16 total posts (Page 1 of 2)   01 | 02   Next

Related Discussions

Related Forums