Project Execution: Product Implementation, Project Closedown

<< Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation

Problems in Software Projects, Process- related Problems >>

Software Project Management (CS615)

LECTURE # 10

2. Software Development Fundamentals

Management Fundamentals

2.9

Project Execution

⇒ Product Implementation

Product implementation activities involve defining processes related to the

implementation of the software product at the customer site. Some of the tasks

that you perform for product implementation are mentioned below:

Implementation plan creation: An implementation plan defines the duration of

implementation and the hard and software perquisites for implementing the

software product.

Support plan creation: the project manager also needs to create a support plan for

the customer. The support plan includes consideration such as the post-

implementation support activities provided to the customer. Post-implementation

considerations include the number of support staff available to the customer, their

names, contact numbers, and the duration of their availability.

Training plan creation: During product implementation, you create a training

plan to train the customer on the software product. The training plan includes

considerations such as the duration of training, the prerequisites for training

people, and the number of people that can be trained simultaneously.

User acceptance plan: You also need to prepare a user acceptance plan. The user

acceptance plan provides a detailed outline on how and when the user acceptance

tests are performed. The primary focus of user acceptance test is to ensure that the

final software product offers all the functionality and performance that the

customer wanted. Therefore, the customer tests the software product for issues

such as aesthetics, user friendless, and scalability.

⇒ Project Closedown

The final activity for a project manager is project closedown. For most software

projects, the project closedown activities take place in the post-implementation

phase. However, in some software projects, the customer requests support

activities for a longer duration. In such cases, the software project is considered

Software Project Management (CS615)

closed immediately after implementation. The tasks that you perform in project

closedown are mentioned below:

Prepare closedown report: The project closedown report contains the results of

the causal analysis that you do for the project. This contains an analysis of what

went wrong, what went right, and what you could have done better in the software

project.

Identify learning: You also need to assess the entire software project and the

results of the causal analysis to identify the key learning points from the software

project. This helps you identify areas of improvement for future projects. The

learning points can also be used by the organization as considerations while

planning and executing the next software project.

Identify reusable software components: Reusing software components enables

you to lower the cost, time, and effort required to complete the software project

successfully. After project closedown, you identify the software components that

can be reused in future projects of similar nature. The software components

prepared for a software project may be complete, partially complete, or in the

design stage. These components or their designs can be assessed for usability in

future projects.

Create reference material: After the project is complete, you can create white

papers and reference documents. This can be a significant contribution to the

organization and the application area of the software by creating an authoritative

knowledge base.

2.10

Project Management Myths

In most cases, you learn the skills required to manage a software project while on

the job. As a result, most software project managers practice a lot of management

techniques that are of doubtful authenticity. Many software project managers

learn about the so-called management skills and concepts that are actually myths.

⇒ Clarifying the Project Management Myths

The following list aims to clarify some of the more prevalent myths in software

project management.

1. Combining the best resources with the worst resources available for a

software project helps to complete the project successfully.

2. A general statement of objectives is sufficient to begin work on the software

project.

Software Project Management (CS615)

3. Allocating extra resources to a late project allows it to catch up with the

project schedule.

4. As software by itself is flexible, you can change the requirements at any point

in the software project life cycle.

5. The management and the customer always impose an unrealistic deadline for

the software project.

6. A software project that meets all the stated objectives is a success.

7. Software maintenance is an easy task and requires less effort than actual

software development.

8. Identifying and reporting errors during the reviews makes the software

developer unhappy and spoils the work environment.

9. Web-enabling an application or adopting client/server; architecture helps to

run software projects smoothly.

Myth: Combining the best resources with the worst resources available for a project

helps to complete the project successfully.

In software projects, combining the best resources with the worst resources drags

down the efficiency and productivity of good resources. This invariably decreases

the speed of the software project, and the project ends much after the specified

deadline.

Myth: A general statement of objective is sufficient to begin work on the software

project.

Many software project managers and customers believe that a general statement

of objectives gives a reasonable idea of the requirements. However, a formal and

detailed description of the customer requirements is needed before the project

commences. The software project manager must ensure that all information

regarding the software project, such as the functions, performance, interfaces,

constraints, assumptions and validation criteria is gathered.

Myth: Allocating extra resources to a late project allows it to catch up with the

project schedule.

A software project is not a mechanical process such as, say; digging an artificial

lake. In case of creating an artificial lake, adding more people to the job can help

dig a larger area in the same time. However, in a software project, adding, more

people actually increases the time required to finish the project. This happens

because a new person joining the project requires time to understand the

Software Project Management (CS615)

requirements of the client, software design, and standards. Moreover, the existing

people in the project need to devote time and effort to train the new people on the

software project. Therefore, allocating additional resources to a risky situation

increases the risk to the software project.

Myth: As software by itself is flexible, changes in the requirements can be made at

any point in the software project life cycle.

Requests for changes are common with all projects. However, the timing of the

change for requests is critical. This is because an untimely change adversely,

impacts the cost of the software project. For example, a change request during the

requirements gathering stage has a relatively low impact on costs. On the other

hand, a change request during, the software construction stage can be extremely

expensive to incorporate. The software project manager must decide with the

customer upon a set of objectives that must be achieved at the end of the project.

In addition, the project manager and the customer must decide on a specific

phase, beyond which only critical change requests are accepted.

Myth: The management and customer always impose an unrealistic deadline for the

software project.

The management and customer usually believe that project managers prepare cost

effort, and time estimates inclusive of buffers. The management and customers

rationalize that if they can cut the buffers by imposing a tight deadline or a low

budget on a project, the project manager would still complete the project on time.

Myth: A software project that meets all the stated objectives is a success.

Customer requirements for a software project are always in two forms, spoken

and unspoken. Usually, the objectives formed from the customer requirements are

based on the spoken requirements. The software project manager must to be

aware of the unspoken requirements and ensure that these are met.

Myth: Software maintenance is an easy task and requires less effort than actual

software development.

If change requests are made toward the end of the project, then maintenance

activities can contribute to large costs and effort overruns. Moreover, contrary to

the popular view, implementing changes in the software product in the

maintenance stage is a painstaking task.

Myth: Identifying and reporting errors during the reviews makes the software

developer unhappy and spoil the work environment.

Software Project Management (CS615)

If a developer makes an error, it is important to point it out so that the error is

fixed in time. A project manager must communicate assertively so that the team

does not lose focus on quality. In addition, letting an error pass may have ripple

effects on the quality of the software product, frustrating the entire team.

Myth: Web-enabling an application or adopting client / server architecture helps to

run software projects smoothly.

No single technology platform, language, or architecture is a one-point solution

for all software projects. All approaches to software development have unique

merits and demerits. For example, if a marketing firm needs to make information

accessible to people at remote locations, then a, Web-based application is a good

option. However, mainframes are still preferred for applications created for the

banking industry.

Table of Contents: