Departmentalization

In drawing up a structure, the question of differentiation crops up. This is the question of how the organization is to he departmentalized. This is often based on staff specialisms, product lines, categories of customer or geographical location, for example.

In the case of software development, it is usually the case that either a functional or a task-oriented approach is used. With functional departmentalization, systems analysts might be put in a group separate from the programmers. The programmers would act as a p<x>l from which resources may be drawn for particular tasks. With a task-oriented approach, the programmers and systems analysts are grouped together in one project team. The project team might be gathered in order to implement a specific long-term project or might exist on a permanent basis to service the needs of a particular set of users.

One ¿idvantage of the functional approach is that it can lead to a more effective use of staff. Programmers can be allocated to jobs as needed and be released for other work when a particular task is completed. For instance, in a project team there are bound to be periods of greater and lesser coding activity and programmers might find there are spells when they are under-utilized. The functional organization will also make it easier for programmers to have careers that are technically oriented - there will probably be a career structure within the software development department that allows the programmer to rise without hav ing to change specialism. This type of organization should also encourage the interchange of new technical ideas among technical staff and the promulgation of company wide standards.

A disadvantage is that having two separate departments can lead to communication problems, especially if a programmer is unfamiliar with the application area. There will also be problems with software maintenance - here it is helpful to have programmers who have built up a familiarity with particular pans of the application software. Users might prefer the established project team approach because, when they require new software features, they will already have a group dedicated to their needs and will not find themselves in the position of always hav ing to fight other departments for development resources. The project team structure tends to favour a pattern of career progression where programmers eventually become systems analysts.

A third method of departmentalization is based on lifccycle phase. Here there are separate teams for development and maintenance. Some staff can concentrate in a focused and sustained manner on developing new applications with few interruptions, while other teams, more oriented towards service and support, deal with maintenance.

Some organizations have attempted to get the best of all worlds by hav ing a matrix structure. In this case the programmer would have two managers: a project leader who would give day-to-day direction about the work in hand and a programming manager who would be concerned about such things as career development.

! I.I ! ORCANT/A HON AL STRUCTURES

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment