Formalizing processes 2

[sstoppel]

My organization is experiencing the growing pains of going from a very small, informal single site company to a multi-site corporate entity and the need to formalize some processes is becoming very apparent.

Can anyone recommend any books, samples, templates, etc. regarding IT Strategic planning, equipment requests, employee hire/termination procedures, etc?

 

[LNBruno]

http://www.pmhut.com/project-management-process

< M!ke >
[small]Where are we going and why am I in this handbasket?[/small]

 

[SQLSister]

I work for a company that has been going through the same thing for tha last year. We have tripled in size since I got here two years ago and have won the three largest contracts in the history of our industry with a subsequent need to have more formal processes for these large clients.

One of the things we have had to to is change our organization so that we can pass a SAS-70 audit. Looking at the requirements for this can help show you what processes you may need to add or adjust as you grow. If you are publicly traded or thinking about becoming publicly traded, you probably also need to look at Sarbanes-Oxely requirements and if you are in the Health industry you need to look at HIPPA.

As you grow, yoour company will need Human Resources specialists if you do not currently have them. They should have access to the employee policy type stuff you need to implement.

On the IT side, I think the first, most critical thing is to insitute a software driven work request system for software changes and hardware support. As the company grows, you won't really know what work is to be done or what priority it takes or be able to justify the need for more people due to backlog if you do not have this. Do not do any work without a request in this system.

In the software area, you may need to add a database team and a QA team at the minimum. You may also need to lock down access to production servers. In a small shop typically everyone can make changes to production. In a large shop changes must be made on dev first then promoted to QA to be tested and then only authorized people can make those changes to production. If you are using a general password that everyone knows to access your database, you need to look at changing that as well. Backups are an area that big companies often take more seriously than small companies. Look at how you are doing backup as and where they are being stored. We have moved to storing some backups off site.

We found here that instituting some of these changes first with the new large contracts and getting people used to working that way on those first, then extending them to the other older work helped make the change easier to manage. That way we could start with a smaller QA team to handle the immediate new contract work and not have to hire enough to do everything all at once. That gave us a chance to get policies and procedures in place with a small group before hiring more people to do addional QA work for previously exisiting clients. Other things, like using some form of work request system, need to be in place through the organization from a specific date forward. Sometimes it is easier to make a complete break with past policies. Managers in your organization will just need to look at what they think needs to change and make the decision to change it gradually or all at once. But make sure they understand that too much all at once makes people crazy. Also people need information in times of great change and they are concerned about losing the very things that made them like working there. A concerted effort to continue to treat people well (assuming you do that now) will pay off in the long run. While some policies (like working hours or working from home etc.) need to be formalized now to prevent abuse, try not to make the new policies much more restrictive than the informal policies were or you will lose your best people in the process.

"NOTHING is more important in a database than integrity." ESquared