Lower Technical Complexity

• More emphasis on existing assets

• Shorter inception and elaboration phases

• Fewer iterations

• More-predictable costs and schedules Figure 14-2. Priorities for tailoring the process framework

My project experience has demonstrated that five people is an optimal size for an engineering team. Many studies indicate that most people can best manage four to seven things at a time. A simple extrapolation of these results suggests that there are fundamentally different management approaches needed to manage a team of 1 (trivial), a team of 5 (small), a team of 25 (moderate), a team of 125 (large), a team of 625 (huge), and so on. As team size grows, a new level of personnel management is introduced at roughly each factor of 5. This model can be used to describe some of the process differences among projects of different sizes.

Trivial-sized projects require almost no management overhead (planning, communication, coordination, progress assessment, review, administration). There is little need to document the intermediate artifacts. Workflow is single-threaded. Performance is highly dependent on personnel skills.

Small projects (5 people) require very little management overhead, but team leadership toward a common objective is crucial. There is some need to communicate the intermediate artifacts among team members. Project milestones are easily planned, informally conducted, and easily changed. There is a small number of individual workflows. Performance depends primarily on personnel skills. Process maturity is relatively unimportant. Individual tools can have a considerable impact on performance.

Moderate-sized projects (25 people) require moderate management overhead, including a dedicated software project manager to synchronize team workflows and balance resources. Overhead workflows across all team leads are necessary for review, coordination, and assessment. There is a definite need to communicate the intermediate artifacts among teams. Project milestones are formally planned and conducted, and the impacts of changes are typically benign. There is a small number of concurrent team workflows, each with multiple individual workflows. Performance is highly dependent on the skills of key personnel, especially team leads. Process maturity is valuable. An environment can have a considerable impact on performance, but success can be achieved with certain key tools in place.

Large projects (125 people) require substantial management overhead, including a dedicated software project manager and several subproject managers to synchronize project-level and subproject-level workflows and to balance resources. There is significant expenditure in overhead workflows across all team leads for dissemination, review, coordination, and assessment. Intermediate artifacts are explicitly emphasized to communicate engineering results across many diverse teams. Project milestones are formally planned and conducted, and changes to milestone plans are expensive. Large numbers of concurrent team workflows are necessary, each with multiple individual workflows. Performance is highly dependent on the skills of key personnel, especially subproject managers and team leads. Project performance is dependent on average people, for two reasons:

1. There are numerous mundane jobs in any large project, especially in the overhead workflows.

2. The probability of recruiting, maintaining, and retaining a large number of exceptional people is small.

Process maturity is necessary, particularly the planning and control aspects of managing project commitments, progress, and stakeholder expectations. An integrated environment is required to manage change, automate artifact production, and maintain consistency among the evolving artifacts.

Huge projects (625 people) require substantial management overhead, including multiple software project managers and many subproject managers to synchronize project-level and subproject-level workflows and to balance resources. There is significant expenditure in overhead workflows across all team leads for dissemination, review, coordination, and assessment. Intermediate artifacts are explicitly emphasized to communicate engineering results across many diverse teams. Project milestones are very formally planned and conducted, and changes to milestone plans typically cause malignant replanning. There are very large numbers of concurrent team workflows, each with multiple individual workflows. Performance is highly dependent on the skills of key personnel, especially subproject managers and team leads. Project performance is still dependent on average people.

Software process maturity and domain experience are mandatory to avoid risks and ensure synchronization of expectations across numerous stakeholders. A mature, highly integrated, common environment across the development teams is necessary to manage change, automate artifact production, maintain consistency among the evolving artifacts, and improve the return on investment of common processes, common tools, common notations, and common metrics.

Table 14-1 summarizes some key differences in the process primitives for small and large projects.

Table 14-1. Process discriminators that result from differences in project size

process primitive

smaller team

larger team

Life-cycle phases

Weak boundaries between phases

Well-defined phase transitions to synchronize progress among concurrent activities

Artifacts

Focus on technical artifacts

Few discrete baselines

Very few management artifacts required

Change management of technical artifacts, which may result in numerous baselines

Management artifacts important

Workflow effort allocations

More need for generalists, people who perform roles in multiple workflows

Higher percentage of specialists

More people and teams focused on a specific workflow

Checkpoints

Many informal events for maintaining technical consistency

No schedule disruption

A few formal events

Synchronization among teams, which can take days

Management discipline

Informal planning, project control, and organization

Formal planning, project control, and organization

Automation discipline

More ad hoc environments, managed by individuals

Infrastructure to ensure a consistent, up-to-date environment available across all teams

Additional tool integration to support project control and change control

14.1.2 Stakeholder Cohesion or Contention

The degree of cooperation and coordination among stakeholders (buyers, developers, users, subcontractors, and maintainers, among others) can significantly drive the specifics of how a process is defined. This process parameter can range from cohesive to adversarial. Cohesive teams have common goals, complementary skills, and close communications. Adversarial teams have conflicting goals, competing or incomplete skills, and less-than-open communications.

A product that is funded, developed, marketed, and sold by the same organization can be set up with a common goal (for example, profitability). A small, collocated organization can be established that has a cohesive skill base and excellent day-to-day communications among team members.

It is much more difficult to set up a large contractual effort without some contention across teams. A development contractor rarely has all the necessary software or domain expertise and frequently must team with multiple subcontractors, who have competing profit goals. Funding authorities and users want to minimize cost, maximize the feature set, and accelerate time to market, while development contractors want to maximize profitability. Large teams are almost impossible to collocate, and synchronizing stakeholder expectations is challenging. All these factors tend to degrade team cohesion and must be managed continuously. Table 14-2 summarizes key differences in the process primitives for varying levels of stakeholder cohesion.

Table 14-2. Process discriminators that result from differences in stakeholder cohesion

process primitive

few stakeholders, cohesive teams

multiple stakeholders, adversarial relationships

Life-cycle phases

Weak boundaries between phases

Well-defined phase transitions to synchronize progress among concurrent activities

Artifacts

Fewer and less detailed management artifacts required

Management artifacts paramount, especially the business case, vision, and status assessment

Workflow effort allocations

Less overhead in assessment

High assessment overhead to ensure stakeholder concurrence

Checkpoints

Many informal events

3 or 4 formal events

Many informal technical walkthroughs necessary to synchronize technical decisions

Synchronization among stakeholder teams, which can impede progress for weeks

Management discipline

Informal planning, project control, and organization

Formal planning, project control, and organization

Automation discipline

(insignificant)

On-line stakeholder environments necessary

14.1.3 Process Flexibility or Rigor

The degree of rigor, formality, and change freedom inherent in a specific project's "contract" (vision document, business case, and development plan) will have a substantial impact on the implementation of the project's process. For very loose contracts such as building a commercial product within a business unit of a software company (such as a Microsoft application or a Rational Software Corporation development tool), management complexity is minimal. In these sorts of development processes, feature set, time to market, budget, and quality can all be freely traded off and changed with very little overhead. For example, if a company wanted to eliminate a few features in a product under development to capture market share from the competition by accelerating the product release, it would be feasible to make this decision in less than a week. The entire coordination effort might involve only the development manager, marketing manager, and business unit manager coordinating some key commitments.

On the other hand, for a very rigorous contract, it could take many months to authorize a change in a release schedule. For example, to avoid a large custom development effort, it might be desirable to incorporate a new commercial product into the overall design of a next-generation air traffic control system. This sort of change would require coordination among the development contractor, funding agency, users (perhaps the air traffic controllers' union and major airlines), certification agencies (such as the Federal Aviation Administration), associate contractors for interfacing systems, and others. Large-scale, catastrophic cost-of-failure systems have extensive contractual rigor and require significantly different management approaches. Table 14-3 summarizes key differences in the process primitives for varying levels of process flexibility.

14.1.4 Process Maturity

The process maturity level of the development organization, as defined by the Software Engineering Institute's Capability Maturity Model [SEI, 1993; 1993b; 1995], is another key driver of management complexity. Managing a mature process (level 3 or higher) is far simpler than managing an immature process (levels 1 and 2). Organizations with a mature process typically have a high level of precedent experience in developing software and a high level of existing process collateral that enables predictable planning and execution of the process. This sort of collateral includes well-defined methods, process automation tools, trained personnel, planning metrics, artifact templates, and workflow templates. Tailoring a mature organization's process for a specific project is generally a straightforward task. Table 14-4 summarizes key differences in the process primitives for varying levels of process maturity.

Table 14-3. Process discriminators that result from differences in process flexibility

process primitive

flexible process

inflexible process

Life-cycle phases

Tolerant of cavalier phase commitments

More credible basis required for inception phase commitments

Artifacts

Changeable business case and vision

Carefully controlled changes to business case and vision

Workflow effort allocations

(insignificant)

Increased levels of management and assessment workflows

Checkpoints

Many informal events for maintaining technical consistency

3 or 4 formal events

Synchronization among stakeholder teams, which can impede progress for days or weeks

Management discipline

(insignificant)

More fidelity required for planning and project control

Automation (insignificant) (insignificant)

discipline

Automation (insignificant) (insignificant)

discipline

Table 14-4. Process discriminators that result from differences in process maturity

process primitive

mature, level 3 or 4 organization

level 1 organization

Life-cycle phases

Well-established criteria for phase transitions

(insignificant)

Artifacts

Well-established format, content, and production methods

Free-form

Workflow effort allocations

Well-established basis

No basis

Checkpoints

Well-defined combination of formal and informal events

(insignificant)

Management discipline

Predictable planning Objective status assessments

Informal planning and project control

Automation discipline

Requires high levels of automation for round-trip engineering, change management, and process instrumentation

Little automation or disconnected islands of automation

Table 14-5. Process discriminators that result from differences in architectural risk

process primitive

complete architecture feasibility demonstration

no architecture feasibility demonstration

Life-cycle phases

More inception and elaboration phase iterations

Fewer early iterations More construction iterations

Artifacts

Earlier breadth and depth across technical artifacts i

(insignificant)

Workflow effort allocations

Higher level of design effort

Lower levels of implementation and assessment

Higher levels of implementation and assessment to deal with increased scrap and rework

Checkpoints

More emphasis on executable demonstrations

More emphasis on briefings, documents, and simulations

Management discipline

(insignificant)

(insignificant)

Automation discipline

More environment resources required earlier in the life cycle

Less environment demand early in the life cycle

14.1.5 Architectural Risk

The degree of technical feasibility demonstrated before commitment to full-scale production is an important dimension of defining a specific project's process. There are many sources of architectural risk. Some of the most important and recurring sources are system performance (resource utilization, response time, throughput, accuracy), robustness to change (addition of new features, incorporation of new technology, adaptation to dynamic operational conditions), and system reliability (predictable behavior, fault tolerance). The degree to which these risks can be eliminated before construction begins can have dramatic ramifications in the process tailoring, Table 14-5 summarizes key differences in the process primitives for varying levels of architectural risk.

14.1.6 Domain Experience

The development organization's domain experience governs its ability to converge on an acceptable architecture in a minimum number of iterations. An organization that has built five generations of radar control switches may be able to converge on an adequate baseline architecture for a new radar application in two or three prototype release iterations. A skilled software organization building its first radar application may require four or five prototype releases before converging on an adequate baseline. Table 14-6 summarizes key differences in the process primitives for varying levels of domain experience.

Table 14-6. Process discriminators that result from differences in domain experience
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