ZeePedia

Project Execution: Product Implementation, Project Closedown

<< Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
Problems in Software Projects, Process- related Problems >>
img
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
80
img
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.
81
img
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
82
img
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.
83
img
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.
84
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration