Introduction

This article deals with the Automation project for a maintenance project in a software company. The project involves automating the processes that are discrete and disparate into a centralized monitoring mechanism via a tool developed for this purpose.

This article lists the scope and the different aspects like resource and schedule planning along with the network diagram and the work breakdown structure.

Project Scope

The scope of the project is to develop an automation tool for centralizing the processes of the work stream. This includes:

• Developing the dashboard as well as the database required for such a purpose.

• Listing out the functional requirements that include monitoring the processes for SLA compliance and throughput definition.

• Maintaining access rights with varying levels of control for the different layers of management.

The timekeeping and other administrative functions are not part of the tool and hence out of scope. The scope is directly related to the output of the deliverables that include the front end and back end components as discussed above.

Resource and Schedule Planning

The project involves having a team of six resources dedicated to the project with a team leader included to oversee the development team.

The resources would be divided into two teams:

1. One team is responsible for design and development and the other team doing the requirements and testing aspects.

2. The second team would have the functional expertise in mapping out the requirements as well as translating the same into usable specifications for the first team.

Further the expertise of this team is to be utilized for testing as well as they understand the scope and the functional aspects of the same.

The schedule of the project would be for a period of two months. The first couple of weeks would be for the requirements from the various stakeholders and the next month would be spent in actual design and coding. The last couple of weeks would be spent in testing and implementing the tool.

Network Diagram

Critical path is as listed above. Since this project involves straight through development, the critical path would be the same as that of the SDLC phases.

Effect of crashing the schedule

In case the schedule is crashed, the requirements phase can be merged with the design phase with parallel activities. This would involve moving beyond the normal “waterfall” model of SDLC and instead having an agile methodology.

Effect of Level loading the resources

The two teams of the resources can be used interchangeably with the requirements that the skills sets of the resources to be the same.

Risk assessment

The risk management plan for the project would be having the following items listed as potential risks and their mitigation plans:

• Resource risk: divided into two components in terms of knowledge acquisition and attrition risk. The first component is mitigated by training and knowledge sharing and the second component is mitigated by documenting the processes and knowledge management

• Scope creep: Any changes to scope must be approved by all the stakeholders with costs to be shared.

• Variance: Any variance in the budget due to time, cost or quality constraints (the “triple constraint”) should be dealt by all the stakeholders. This is to be done by regular status reporting and identification of potential issues to be resolved by the various stakeholders

• Technology: Any change in technology would pose an immediate risk to the project and it should be ensured that proper technology is selected for the same.

Conclusion

This article has attempted to portray some aspects of the project management processes taking an example of an automation tool for a maintenance project in a software company. While this is by no means comprehensive, it does address some of the questions listed in the assignment.