IT Employment

Ask something
Discussion Locked

App/Dev Dept, Organizational Structure?

0 helpful
5 replies

by jim james

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

We are currently looking at restructuring our App/dev department as we "centralize" our organization from a number of small groups of dev/DBA staff working within user departments, supporting their local applications to a organizational pool of App/Dev resources that are assigned to projects as required. (If that makes sense at all!!)

We are looking to restructure into the following units;
Business Analysis/Project Management
Application Development
Application Maintenance

With this brief description does anyone work in a similar environment, or an app/dev structure that works really well that could possibly be adapted here? Any direction/opinion is appreciated.

Thanks
Jim

5 replies

by james r linn

Depending of course on your company size, department size and the complexity of the apps you support, you may want to break this down.

I think splitting development and maintenance into two groups is a problematic exercise. You will deinfinately be stigmatising those chosen to do maintenance and elevating the status of the developers. Personally we split into the application type(in house apps in one groups, ERP support(customizations/reports) into another. Everone does maintenance, testing and 3rd level support unless they have been dedicated to a project.

I have worked in larger orgs where they did have separate dev and maintenace groups and I find this didn't work as well from the customers perspective.

You could also look at resource pooling - everyone goes into the pot, and project managers request resources from a resource pool manager who assigns them. This is probably better done with a mature organization - cause its sink or swim in the pool - the poorer performers tend to sink.

James

by littledragon

When I worked for a very large international bank's IT organization, they went from a decentralized (geographically as well as organizationally) IS structure to one that was organizationally centralized (all IS development and maintenance staff reported to the same Head of IT), but they were logically divided into groups with dotted line reporting responsibilities to the business units they served.

The common IT management meant that the company could maintain some common IT standards and architecture across the organization, but the dotted line reporting of the various development/support teams meant better responsiveness to user requirements. It seemed to work fairly well and provided a good balance between the techie versus business objectives.

I agree that separating development from maintenance is not a good idea. The problem goes beyond jealousy over work assignments. If there is no cross-over of responsibilities, there is little incentive for developers to create code that is error-free and easy to maintain. The developers aim for time and budget targets that make them look good, which results in the poor support staff getting stuck with poor quality applications that cost the company more in the long run due to lost productivity and rework efforts. Keep the two together, or at least rotate responsibilities periodically so no one does just one or the other for too long a time.

This discussion is closed to new replies.