Download Project Execution: Product Implementation and more Study notes Software Project Management in PDF only on Docsity!
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
docsity.com
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.
- Combining the best resources with the worst resources available for a software project helps to complete the project successfully.
- A general statement of objectives is sufficient to begin work on the software project.
docsity.com
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.
docsity.com
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.
docsity.com
