§4.0 | Introduction | §4.2 | Management Technique | |
§4.1 | Management Structure | §4.3 | Footnote - Image |
We now know, or should, something of
And soon we will be looking at some associated concerns
What other basic knowledge do we need to create, or to monitor the activities of, a computing or software company? Answer, quite a lot, to do the job properly! But common sense and experience, and a little now on internal company services and management, will get us by.
Bott, Coleman, Eaton & Rowland in their "Professional Issues in Software Engineering" devote a chapter to the analysis of a single company - read it! Or, of course, the similar material in later texts.
Here, we look very briefly at a typical organisational structure for a small company, and at some of the general issues associated therewith.
We have already looked briefly at this area, when we were thinking about the geographical or functional company organisation under which a company was constituted. Here, we are concerned to take a closer look at how that organisation might be developed into a proper management structure.
There are many ways of doing this, some flat (as, for example, at Agilent), some highly hierarchical (probably the norm). The most obvious pattern is a straight-forward structure of divisions, each with its own director; the diagram gives a simple example - but an example which also displays a number of important points.
Note the separation which is made between the two branches labelled
It is vital for a company's long-term health that R&D staff are not side-tracked into the day to day urgencies of close-to-market operations.
And it is, if anything, even more vital that responsibility for quality control is independent of the operational line management. Quality control really does matter!
But you get nothing for nothing in this world ... and the down side of this independence is that a particular worker can all too easily receive conflicting instructions about priorities. Careful and responsible management will ensure that this does not happen, for if it does the staff will rapidly lose confidence in the company ... and then quality will suffer, the very thing we are trying to avoid.
There is also a danger of conflict between other branches, the essential dichotomy being
Do it well ... | ||
... and sell it later | ||
versus | Make money now |
but usually the lines of management can be sufficiently clear to eliminate this conflict.
Note also that "Personnel" - Human Resource Management as it is now increasingly known - is a free-standing branch. This is a reflection of the extent to which any service company, but especially one in the skill-intensive world of computing, is heavily reliant on the quality of its staff.
Frequently small companies suppress this role, placing it under one or other of "Operations" or "Finance" ...
... but either of those choices leads to another, and potentially serious, conflict of interest. This is a point which our normally good textbook fails to bring out.
"Personnel" - HRM - should have an important moderating role to play, carefully balancing the interest of the company and of the staff, in addition of course to arranging all the things like
The other headings used in the diagram are essentially self-explanatory, linked to what has gone before in the earlier chapters of these notes.
There is one pragmatic but rather different point we should take from our structural considerations, concerned with effective chains of delegation and reporting:
Whenever you are dealing with management, which necessarily means with inter-personal relations, much depends on the personalities of the people involved ...
... the management structure, of course, should only marginally be influenced by the personalities involved (theory says, not at all, but we all have to live in the real world and make things work!), but the effectiveness of the structure is determined by the people who operate it.
| |||||||||||
Source: 'Fiennes on Rails', Gerard Fiennes, David & Charles (1986) |
One popular (currently fashionable?) technique is Just in Time Management, which presumably derives from the financially-driven - and very successful - techniques of just in time maintenance, often applied to mechanical and civil engineering structures. Although well known to students, and indeed to some lecturers, it can hardly be recommended as a management technique ...
... too much can go wrong at the last minute!
But, curiously, the just in time approach does give some good guidance on dealing with staff ...
... clear direction, yes, but usually a minimum level of control will pay dividends.
More officially correct, and in practice more sensible, is the idea of Management by Objectives:
Our rudimentary organisational chart in §4.1 referred to 'sales'
Though the question of company image goes much beyond that, and needs to be adjusted skillfully if the company wants to move into some new product area:
Marketing and the overall image of a company are
© Paul Goldfinch 2008 | Next Chapter | Return to CS 302 Menu |