Personnel Planning-Software Engineering

Dhanapriya D

Personnel planning 

Personnel planning focuses on staffing appointing the right personnel for the roles defined by the organizational structure.

It involves key activities such as:

  • Defining personnel requirements
  • Recruiting (identifying, interviewing, and selecting candidates)
  • Compensating employees
  • Developing and promoting staff

For effective personnel planning and scheduling, it is essential to estimate the effort and schedule size for subsystems and components within the project.

At the early planning stage, when the system design is not yet complete, planners can typically only outline the major subsystems and their key modules. Once the project plan is prepared and the effort and timelines for different phases are known staffing requirements can be determined.

From the total project cost and duration, the average staff size can be calculated by dividing total effort (in person-months) by the overall project duration (in months).

In practice, staffing needs vary across phases:

  • Requirement and design: fewer personnel needed
  • Implementation and testing: peak staffing required
  • Integration and final testing: staff requirements decline again

Models like COCOMO help estimate staff requirements for each phase, since effort and schedule values are already available.

With the schedule and average staffing levels defined for all project activities, managers can prepare a comprehensive personnel allocation plan. This plan clearly indicates how many people will be needed for each task at different times throughout the project, making it easier to calculate monthly effort distribution and overall phase-wise effort. 

Team Structure

Team structure refers to the way individual project teams are arranged to carry out tasks effectively. Different approaches can be used to organize project teams, depending on the size and complexity of the problem at hand. Broadly, there are three formal team structures: Chief Programmer, Ego-less (Democratic), and Mixed team organizations. In practice, several variations of these models also exist. Choosing the right structure is crucial, as different projects often demand different arrangements to achieve the best outcomes.

Ego-Less or Democratic Teams

Ego-less teams are typically composed of a small group of programmers who work collaboratively toward a shared goal. Decisions are made through consensus, with every member’s input considered before arriving at significant outcomes. Leadership is not fixed but rotates among team members, which is why ego-less teams are often referred to as democratic teams.

This structure encourages equal participation from all members, fostering diverse perspectives that can lead to stronger, well-rounded solutions. Because of its collaborative and flexible nature, this model is particularly effective for long-term, research-oriented projects where strict deadlines are not a primary concern.

Chief Programmer Team

Unlike ego-less teams, a chief programmer team follows a clear hierarchical structure. At the core is the chief programmer, supported by a backup programmer, a program librarian, and additional programmers.

The chief programmer plays a central role, making all major technical decisions and handling most of the system design. Once the design is ready, specific coding tasks are delegated to the team members.

The backup programmer mirrors the chief programmer’s technical expertise and steps in if the chief programmer becomes unavailable due to illness or departure.

The program librarian ensures proper organization and maintenance of documentation, records, and other communication materials, which are critical for smooth project execution.

Controlled Decentralized Team (Hierarchical Team Structure)

The controlled decentralized team is a hybrid model that combines the strengths of both democratic (ego-less) and chief programmer team structures.

In this setup, a project leader oversees the team, supported by senior programmers. Each senior programmer, in turn, leads a group of junior programmers. Within these small groups, the members operate much like an ego-less team, collaborating and sharing responsibility. However, communication between different groups takes place only through the senior programmers, who also coordinate directly with the project leader.

This structure establishes a balance: it has fewer communication channels than a fully democratic team but more than a strictly hierarchical chief programmer team. As a result, it is particularly effective for managing large, moderately complex projects. However, it is less suitable for very simple tasks or open-ended research projects.


Our website uses cookies to enhance your experience. Learn More
Accept !