Ads
  

Characteristics of an Organization

Characteristics of an Organization

Many dimensions must be examined in the assessment of the organizational climate for managing a software development project in an organization:

● Model;
● Maturity;
● Thickness;
● Size;
● Dispersion;
● Structure.

But first, let's define what an organization is. Management literature includes many definitions:

●  "An organization is a system that exchanges materials, personnel, manpower, and energy with the environment." - James L. Bowditch and Anthony F. Buono
●  "An organization is group of people with stated and formal goals." - Paul Hersey and Kenneth H. Blanchard
●  "Organizations can be defined as groups of people who must coordinate their activities in order to meet organizational objectives." - Harold Kerzner

Some of these emphasize different characteristics. The definition that we'll use separates a collection from a group, and a group from an organization. A collection is just a bunch of people who are not interacting, with or without a common purpose. People in an elevator are a usually just a random collection of people sharing a public space. They become a group if they begin to interact with one another, and they become an organization if a goal is defined and some rules for group behavior are put in place (implicitly or explicitly). So, an organization is an interacting group of people with a unifying goal. A bunch of random people (a collection) who get trapped in an elevator soon become a group, and then an organization, with the unifying goal of trying to get out. Major interaction begins. Goals, roles, and rules are verbally established. Leaders and specialists emerge, and, hopefully, so do they finally.

But this is just a word model. Some kind of visual organizational model should be illustrated. Management and organizational behavior literature is full of them, so they are not hard to find. But mapping an organization to some kind of model is important because it gives us a framework for understanding and change.

Generic Model of an Organization

It seems that there are almost as many organizational models as there are organizations in the world. Let's consider a generic model for an organization to understand the basic elements. Henry Mintzberg explained a generic organization as having five main parts:

●  Strategic apex - leadership that sets strategic direction;
●  Middle line management - translation of strategic direction into tactical plans;
●  Operating core - execution of the plans to produce the product/service;
●  Technostructure - technical infrastructure supporting the operating core;
●  Support staff - people infrastructure supporting all the organization's parts.

These are shown in Figure 1. Some call this the "mushroom cloud" depiction of an organization (a joke). But the center represents the main function of the business (to produce services such as software engineering and products such as software executable products). The technostructure generally consists of the engineering functions that describe the main business (semiconductor manufacturing, Web design services, etc.), and the support staff contains administrative services, computer and network support, human resources, and so on).

A Generic Organizational Structure

You can imagine any project organization as needing the same elements to be effective. If the project operates within a larger organization, then it may rely on the technostructure and support staff for many of its basic operating needs. The strategic management for a project comes from the project manager, through interpretations of the goals of the customer, expressed in requirements. The support staff and technostructure for software engineering projects contain configuration management, network support, and administrative services such as copying and supply management. The operating core for a software project are the software engineers who construct and implement the design using computer technology, often in small teams led by middle line managers or subproject managers.

Does Organization Size Matter?

Obviously, size is an important characteristic for an organization performing projects and programs. The size of the desired system product determines the size of the organization required to produce it. The number of human interactions available and necessary in a project organization is one determinant of the project management climate in an organization. More people are not necessarily better, though.

If the size of the effort is important, what size is important in most businesses? Projects and programs operate within a larger business systems context, and, in fact, many businesses are completely organized around projects. Startup companies tend to have a lot of projects going on at once to put some revenue-generating products into service as quickly as possible. These businesses are totally organized around products and services, which must be market-sensitive. It is useful to consider a range of possible projects within two dimensions: staff size and project length. Figure 2 shows that not enough staff working on a project that stretches out too long results in an insensitivity to the marketplace, whereas too many people working on a "crash" project is impossible to manage. New products and major assets tend to follow a band moving from the lower left to the upper right. The scales for the x- and y-axes in this figure, and the width of the "sweet spot" band, will vary for most companies, but the general
principle and relationships hold true.                                           

Market Sensitivities to Project Size and Duration

Dispersed or Collocated

Another factor related to size is dispersion. The more widely dispersed a project team organization is, the more complicated it is for the people within it to interact. Today's telecommunications technologies have blurred many boundaries, but there is still nothing like face-to-face human interaction for getting things done. Figure 3 illustrates dispersed and collocated team member's interactions. The collocated team members share the same room, floor, building, or office campus (1), whereas the dispersed team members are in separate facilities (1, 2, 3, and 4), perhaps halfway around the world from each other. This situation produces special problems for the software development project manager. Cultural differences emerge, and it becomes physically harder to communicate due to time shifts, language issues, and the difficulty of maintaining a common technical and project infrastructure.

Dispersed and Collocated Project Team Organizations

The Relative Power of the Project Manager


Another important dimension for a project organization is how much authority and power the project manager has. We can think of an ideal software development project manager as the CEO of the project, with everyone involved reporting to him (and no one else). Unfortunately, this is rarely the case. But a project manager with no power is unlikely to get anything done. Power over others can come from several sources. According to Hersey and Blanchard, the types of power that a project manager might have are:

1Legitimate  - the perception that it is appropriate for the leader to make decisions due to title or position in the organization;
2.  Reward -  the perceived ability to provide things that people would like to have;
3.  Connection -  the perceived association with influential persons or organizations;
4.  Coercive -  the perceived ability to provide sanctions or consequences for nonperformance;
5.  Expert -  the perception that the leader has relevant education, experience, and expertise;
6.  Information -  the perceived access to or possession of useful information;
7.  Referent -  the perceived attractiveness of interacting with another person.

Numbers 1, 2, 3, and 4 in the list are based on a person's position in the organization and are called the positional power types. Numbers 5, 6, and 7 are called the personal power types. Technically oriented software engineers who rise to project leadership often have a great deal of expert and informational power. If they are well liked, then they also have referent power. Their leadership position gives them varying amounts of positional power, depending on the organization structure of the surrounding environment.

Organizational Maturity

Consider the maturity of the organization. Startups seem to behave differently from long-established corporations. They are typically characterized as flexible, fluid, energetic, and usually small. Maturity has to do with the formality of the processes they define and follow.

Characteristics of immature organizations include:

●  Ad hoc processes, improvised by their practitioners and management;
●  Processes and rules that are not rigorously followed or enforced;
●  High dependence on current practitioners;
●  Likeliness of having cost and schedule problems;
●  Product or service functionality and quality compromised to meet schedule;
●  Quality that is difficult to predict.

To an outsider looking in, an immature organization's processes may look like Figure 4.

Immature Processes as Observed from Outside the Organization

In contrast, some characteristics of mature organizations are:

●  Processes that are defined, documented, and continuously improving;
●  Documented processes that are consistent with the way work actually gets done;
●  Visible support by management and engineering;
●  Well-controlled, audited, and enforced policies;
●  Product and process measurements that are gathered and used;
●  Disciplined use of technology.

A mature organization's processes may look more like Figure 5 to an outsider.

Mature Processes as Observed from Outside the Organization

Related closely to maturity is thickness or thinness of the organization's culture. Well-understood and followed norms, rules, and processes characterize a thick culture. The IBM of the 1980s was routinely explained as a thick corporate culture, with long-established and set ways to behave, embodied in many formal processes for doing almost anything. Many analysts thought that it got too thick to be responsive to the rapidly changing computer marketplace. Thin cultures tend to be far looser and more individualistic. Your average dotcom startup company fits that model.


Tags

software development project, software executable products, software engineering projects
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus