How do we reinforce a strong management program?

[solidstar]

In relation to a criteria of our project such as scheduling. We thought that an inferior standard in change control management can affect our systems security and even our networks. How do we reinforce a strong management program? Which do you think is the best way to assist us with identifying changes, which is to allow and which is to prevent? Do we need the help of an information technologist or a consultant for a change management?

 

[dave_the_nerd]

In relation to a criteria of our project such as scheduling. We thought that an inferior standard in change control management can affect our systems security and even our networks. How do we reinforce a strong management program?

Basically comes down to writing everything down, and having multiple people (stakeholders) signing off on changes. There are any number of tools that can be used to do this, whether they're intended for the purpose of not. (I might start with a combination of Bugzilla and Racktables, for instance.) Don't get too distracted by pretty graphs - which tool you use doesn't matter as much as having a process that includes review, comment, and well documented implementation phases.

Which do you think is the best way to assist us with identifying changes,

Potential changes to implement are usually driven by need. Customer issues, developer issues, or an internal driver, like seeing an opportunity to enhance efficiency. Don't change stuff for the sake of changing it.

which is to allow and which is to prevent?

That's up to your development and networking (since you mentioned those) teams. Probably managers, or a senior engineer. Obviously, legal restrictions come first, then business needs, then things like maintainability and ease of use.

Do we need the help of an information technologist or a consultant for a change management?

Possibly. There are a number of project management certifications and "schools", and as a result, no shortage of process consultants. This isn't super-complicated - you should be able to drive it internally. But if you have political problems, influential people resisting change, then sometimes it's more expedient to bring in an outside person to be the "bad guy."

The only thing I have to say about hiring consultants is that IME they require at least double the management attention vs. an internal employee. (You've gotta get them up to speed on your existing operations and the history of your product in order for them to make helpful recommendations, and that takes billable hours.)

The biggest hurdle here, usually, is the culture shift from a flying-by-the-seat-of-the-pants, anything-goes organization (a lot of startups), to something more stodgy. You only go down this road if you've done the math and being reliable is more important than being agile and disruptive. In other words, if you're moving from a rapid development mindset (move fast and break things) to a support/sustaining role with an existing customer base. It's not fun - expect to lose some people.

 

[sao123]

My only suggestion is to NOT mix ITIL principles with Agile principles... you will end up with a disastrous management scheme. if you are going to be agile, be agile.
if you are going to be ITIL, be ITIL.

 

[solidstar]

Basically comes down to writing everything down, and having multiple people (stakeholders) signing off on changes. There are any number of tools that can be used to do this, whether they're intended for the purpose of not. (I might start with a combination of Bugzilla and Racktables, for instance.) Don't get too distracted by pretty graphs - which tool you use doesn't matter as much as having a process that includes review, comment, and well documented implementation phases.

I actually received few offers from providers, one is from ETQ.

Potential changes to implement are usually driven by need. Customer issues, developer issues, or an internal driver, like seeing an opportunity to enhance efficiency. Don't change stuff for the sake of changing it.

This is a good advice!

That's up to your development and networking (since you mentioned those) teams. Probably managers, or a senior engineer. Obviously, legal restrictions come first, then business needs, then things like maintainability and ease of use.

Possibly. There are a number of project management certifications and "schools", and as a result, no shortage of process consultants. This isn't super-complicated - you should be able to drive it internally. But if you have political problems, influential people resisting change, then sometimes it's more expedient to bring in an outside person to be the "bad guy."

The only thing I have to say about hiring consultants is that IME they require at least double the management attention vs. an internal employee. (You've gotta get them up to speed on your existing operations and the history of your product in order for them to make helpful recommendations, and that takes billable hours.)

The biggest hurdle here, usually, is the culture shift from a flying-by-the-seat-of-the-pants, anything-goes organization (a lot of startups), to something more stodgy. You only go down this road if you've done the math and being reliable is more important than being agile and disruptive. In other words, if you're moving from a rapid development mindset (move fast and break things) to a support/sustaining role with an existing customer base. It's not fun - expect to lose some people.

Sounds great! I guess you answered all my inquiries. And All I need to do is to read your comment over and over again. Thank you very much![/QUOTE]