Personnel Planning
Personnel Planning deals with staffing. Staffing deals with the appoint personnel for the position that is identified by the organizational structure.
It involves:
- Defining requirement for personnel
- Recruiting (identifying, interviewing, and selecting candidates)
- Compensating
- Developing and promoting agent
For personnel planning and scheduling, it is helpful to have efforts and schedule size for the subsystems and necessary component in the system.
At planning time, when the system method has not been completed, the planner can only think to know about the large subsystems in the system and possibly the major modules in these subsystems.
Once the project plan is estimated, and the effort and schedule of various phases and functions are known, staff requirements can be achieved.
From the cost and overall duration of the projects, the average staff size for the projects can be determined by dividing the total efforts (in person-months) by the whole project duration (in months).
Typically the staff required for the project is small during requirement and design, the maximum during implementation and testing, and drops again during the last stage of integration and testing.
Using the COCOMO model, average staff requirement for various phases can be calculated as the effort and schedule for each method are known.
When the schedule and average staff level for every action are well-known, the overall personnel allocation for the project can be planned.
This plan will indicate how many people will be required for different activities at different times for the duration of the project.
The total effort for each month and the total effort for each step can easily be calculated from this plan.
Team Structure
Team structure addresses the issue of arrangement of the individual project teams. There are some possible methods in which the different project teams can be organized. There are primarily three formal team structures: chief programmer, Ego-less or democratic, and the mixed team organizations even several other variations to these structures are possible. Problems of various complexities and sizes often need different team structures for the chief solution.
Ego-Less or Democratic Teams
Ego-Less teams subsist of a team of fewer programmers. The objective of the group is set by consensus, and input from each member is taken for significant decisions. Group leadership revolves among the group members. Due to its nature, egoless teams are consistently known as democratic teams.
The structure allows input from all representatives, which can lead to better decisions in various problems. This suggests that this method is well suited for long-term research-type projects that do not have time constraints.
Chief Programmer Team
A chief-programmer team, in contrast to the ego-less team, has a hierarchy. It consists of a chief-programmer, who has a backup programmer, a program librarian, and some programmers.
The chief programmer is essential for all major technical decisions of the project.
He does most of the designs, and he assigns coding of the different part of the design to the programmers.
The backup programmer uses the chief programmer makes technical decisions, and takes over the chief programmer if the chief programmer drops sick or leaves.
The program librarian is vital for maintaining the documentation and other communication-related work.
This structure considerably reduces interpersonal communication. The communication paths, as shown in fig:
Controlled Decentralized Team
(Hierarchical Team Structure)
A third team structure known as the controlled decentralized team tries to combine the strength of the democratic and chief programmer teams.
It consists of project leaders who have a class of senior programmers under him, while under every senior programmer is a group of a junior programmer.
The group of a senior programmer and his junior programmers behave like an ego-less team, but communication among different groups occurs only through the senior programmers of the group.
The senior programmer also communicates with the project leader.
Such a team has fewer communication paths than a democratic team but more paths compared to a chief programmer team.
This structure works best for large projects that are reasonably straightforward. It is not well suited for simple projects or research-type projects.
