Software Project Management: Project Planning
2 likes•4,884 views
The document outlines a project plan for developing a web-based research collaboration platform, including a detailed work breakdown structure, team roles, methodology using agile and scrum approaches, and a comprehensive procurement management section. The project aims to enhance manuscript review processes, ensuring higher acceptance rates for researchers by promoting effective communication and collaboration among team members. Key sections include human resource management, risk management, change management, and quality assurance measures to ensure successful project execution within a four-month timeline.
Software Project Management: Project Planning
- 2. 1 Contents 1. Project Summary ....................................................................................................................................3 2. Methodology............................................................................................................................................3 3. Work Breakdown Structure and estimates ..........................................................................................4 4. Sequence of Activity................................................................................................................................5 5. Timeline ...................................................................................................................................................6 6. Human Resource Management..............................................................................................................6 6.1 Roles and Responsibilities ................................................................................................................7 6.3 Project Organizational Charts.......................................................................................................10 6.4 Staffing Management......................................................................................................................11 7. Procurement Management...................................................................................................................11 7.1 Procure Management Approach ...................................................................................................11 7.2 Procurement Definition..................................................................................................................12 7.3 Type of Contract to be used ...........................................................................................................12 7.4 Procurement Risks..........................................................................................................................12 7.5 Procurement Risk Management....................................................................................................12 7.6 Cost Determination.........................................................................................................................13 7.7 Procurement Constraints ...............................................................................................................13 7.8 Contract Approval Process ............................................................................................................14 7.9 Decision Criteria .............................................................................................................................14 7.10 Vendor Management ....................................................................................................................15 8. Risk Management .................................................................................................................................15 8.1 Risk Identification...........................................................................................................................15 8.3 Risk Qualification and Prioritization............................................................................................16 8.4 Risk Monitoring ..............................................................................................................................16 8.5 Risk Mitigation and Avoidance .....................................................................................................17 8.6 Risk Register....................................................................................................................................17 9. Configuration Management.................................................................................................................18 9.1 Roles and Responsibilities ..............................................................................................................18 9.2 Configuration Control....................................................................................................................19 9.3 Configuration Status Accounting ..................................................................................................19 9.4 Change Request Form....................................................................................................................20 10. Communication Plan ..........................................................................................................................22
- 3. 2 10.1 Communications Management Approach..................................................................................22 10.2 Communications Management Constraints ...............................................................................22 10.3 Stakeholder Communication Requirements ..............................................................................23 10.4 Roles ...............................................................................................................................................23 10.5 Communication Methods and Technologies...............................................................................25 10.6 Communications Matrix ..............................................................................................................26 10.7 Guidelines for Meetings................................................................................................................27 11. Change Management..........................................................................................................................27 11.1 Change Management Approach..................................................................................................27 11.2 Definitions of Change ...................................................................................................................28 11.3 Change Control Board .................................................................................................................29 11.4 Roles and Responsibilities ............................................................................................................30 11.5 Change Control Process ...............................................................................................................30 11.6 Change Management Log ............................................................................................................31 11.7 Change Management log format .................................................................................................33 12. Quality Assurance...............................................................................................................................33 12.1 Quality Management Approach ..................................................................................................33 12.2 Quality Requirements / Standards ..............................................................................................34 12.3 Quality Assurance.........................................................................................................................35 12.4 Quality Control Measurements ...................................................................................................36 13. Release..................................................................................................................................................37 14. Budget ..................................................................................................................................................38 14.1 Measuring Project Costs ..............................................................................................................38 14.2 Reporting Format .........................................................................................................................38 14.3 Cost Variance Response Process .................................................................................................39 14.4 Cost Change Control Process.......................................................................................................39 14.5 Project Budget...............................................................................................................................39
- 4. 3 1. Project Summary Software Project Management course teacher has recently approved the Researchcolab.com project to move forward for project initiation as an academic project. This project will result in the development of a research collaboration and data collection’s web based platform. It will perform this features through review management, data sharing, idea discussion and profiles management. This project will result in greater acceptability of researcher’s work by performing an extensive manuscript review. Expert reviewer will investigate every research element of researcher’s paper, such as soundness of study design, reporting of method, significance to field, ethical soundness, and sufficiency of data analysis. They’ll also provide a detailed check of journal compatibility to minimize chances of rejection. 2. Methodology The requirements and solutions of this project evolve through collaboration between a cross- functional teams. Agile software development process is best suite in this scenario and will be followed in this project. To control the project coordination and continuous improvement the scrum process will be followed. The team members will have meetings in regular interval and discuss about their progress and difficulties they will face. We have formed our team with seven members. The team will be working for a real life project for approximately four months. To reach optimum goal, the whole activities within the project are divided into many tasks and the members are assigned to that specific task. Though there are many tasks need to be done within four months and some of our team members are efficient enough to work, we have selected the best person to play the role in the team. Some of our members are assigned to multiple tasks but they have their own special role for the project. The following table contains name of the team members and project responsibilities that are assigned to that person. Name of the member Assigned task Md. Adiluzzaman Adil Project Management Minhas Kamal System Analysis Kishan Kumar Ganguly Development Md. Rakib Hossain Quality Assurance Mostaque Ahmed Documentation A.H.M. Azimul Haque Communication & Collaboration Israt Fatema Shantu Documentation
- 5. 4 3. Work Breakdown Structure and estimates The WBS for this project is shown in the table below. Level 1 Level 2 Level 3 Milestones Date 1 Researchcolab 1.1 Initiation 1.1.1 Evaluation & Recommendations 1.1.2 Develop Project Charter 1.1.3 Deliverable: Submit Project Charter 1.1.4 Project Sponsor Reviews Project Charter 1.1.5 Project Charter Signed/Approved Project Defined and Initiation Performed 30 Sep, 2016 16 Oct, 2016 19 Oct, 2016 20 Oct, 2016 29 Oct, 2016 1.2 Planning 1.2.1 Create Preliminary Scope Statement 1.2.2 Determine Project Team 1.2.3 Project Team Kickoff Meeting 1.2.4 Develop Project Plan 1.2.5 Submit Project Plan 1.2.6 Milestone: Project Plan Approval Scope and Plan Described 30 Oct, 2016 1 Nov, 2016 2 Nov , 2016 2 Nov , 2016 3 Nov , 2016 3 Nov , 2016 1.3 Execution 1.3.1 Project Kickoff Meeting 1.3.2 Verify & Validate User Requirements 1.3.3 Design System 1.3.4 Procure Hardware/Software 1.3.5 Install Development System 1.3.6 Testing Phase 1.3.7 Install Live System 1.3.8 User Training 1.3.9 Go Live Execution Performed 4 Nov, 2016 6 Nov, 2016 8 Nov, 2016 11 Nov, 2016 12 Nov, 2016 15 Nov, 2016 16 Nov, 2016 17 Nov, 2016 17 Nov, 2016 1.4 Control 1.4.1 Project Management 1.4.2 Project Status Meetings 1.4.3 Risk Management 1.4.4 Update Project Management Plan Project Documents Updated 17 Nov, 2016 18 Nov, 2016 17 Nov, 2016 18 Nov, 2016 1.5 Closeout 1.5.1 Audit Procurement 1.5.2 Document Lessons Learned 1.5.3 Update Files/Records 1.5.4 Gain Formal Acceptance 1.5.5 Archive Files/Documents Project Complete 18 Nov, 2016 18 Nov, 2016 18 Nov, 2016 19 Nov, 2016 19 Nov, 2016
- 6. 5 4. Sequence of Activity 1 Researchcolab 1.1 Initiation 1.1.1 Evaluation & Recommendations 1.1.2 Develop Project Charter 1.1.3 Deliverable: Submit Project Charter 1.1.4 Project Sponsor Reviews Project Charter 1.1.5 Project Charter Signed/Approved 1.2 Planning 1.2.1 Create Preliminary Scope Statement 1.2.2 Determine Project Team 1.2.3 Project Team Kickoff Meeting 1.2.4 Develop Project Plan 1.2.5 Submit Project Plan 1.2.6 Milestone: Project Plan Approval 1.3 Execution 1.3.1 Project Kickoff Meeting 1.3.2 Verify & Validate User Requirements 1.3.3 Design System 1.3.4 Procure Hardware/Software 1.3.5 Install Development System 1.3.6 Testing Phase 1.3.7 Install Live System 1.3.8 User Training 1.3.9 Go Live 1.4 Control 1.4.1 Project Management 1.4.2 Project Status Meetings 1.4.3 Risk Management 1.4.4 Update Project Management Plan 1.5 Closeout 1.5.1 Audit Procurement 1.5.2 Document Lessons Learned 1.5.3 Update Files/Records 1.5.4 Gain Formal Acceptance 1.5.5 Archive Files/Documents
- 8. 7 6. Human Resource Management The purpose of the Researchcolab Human Resource Plan is to achieve project success by ensuring the appropriate human resources with the necessary skills are acquired, resources are trained if any gaps in skills are identified, team building strategies are clearly defined, and team activities are effectively managed. If used effectively, this plan will serve as a tool to aid in the management of this project’s human resource activities throughout the project until closure. This human resources management plan includes: Roles and responsibilities of team members throughout the project Project organization charts Staffing management plan 6.1 Roles and Responsibilities Project Team roles and responsibilities: All team members must clearly understand their roles and responsibilities in order to successfully perform their portion of the project. Listed below are the roles and responsibilities for the Researchcolab.com project team: Project Manager (1 position) – Responsible for all management for the Researchcolab.com Project. Responsible for planning, creating, and/or managing all work activities, variances, tracking, reporting, communication, staffing, and internal coordination with course coordinator. Designer (1 position) Responsible for all design and analysis of the Researchcolab.com project. The designer will assist the implementation work in the distribution and monitoring of the Researchcolab.com.
- 9. 8 Programmer (1 position) – Responsible for coding and programming for the Researchcolab.com Project. Responsible for risk identification, determining impacts of change and configuration change requests, and status reporting. Must be proficient in programming Language: C#, Platform: ASP.NET, Framework: MVC, Backend: ASP.NET MVC Entity Framework Code First, Frontend: Razor , Database: SQLServer. Quality Assurer (1 position) – Responsible for assisting the Project Manager in creating and tracking quality control and assurance standards. Responsible for maintaining quality control and assurance logs, and configuration management throughout the project. Technical Writer (1 position) – Responsible for compiling all project documentation and reporting into standard organizational formats. Responsible for assisting the Project Manager in Configuration Management and revision control for all project documentation. Testing Specialist (1 position) – Responsible for helping establish testing specifications for the Researchcolab.com Project with the assistance of the Programmers. Responsible for ensuring all testing is complete and documented. Responsible for ensuring all testing resources are coordinated. Trainer and communication Lead (1 position)- Identify team member with skills need for project roles.
- 10. 9 Identify & schedule necessary training for team members within IIT. Schedule necessary recreation as motivation purpose for project team members. Responsible for writing duties during all project meetings and maintaining all project communication distribution lists. Project Stakeholders Roles & Responsibilities Listed below are the roles and responsibilities for the Researchcolab.com project stakeholders: Project Sponsor Provides vision, direction, and policy leadership for the project Assists in removing barriers and supports change management initiatives Participates in the Steering Committee, and provides support to this group as needed Has overall authority for the project Responsible for ensuring that deliverables and functionality are achieved as defined in the Project Charter and subsequent project plans Steering Committee Acts as the Project stakeholders group Ensures that the deliverables and functionality of the project are achieved as defined in the project initiation documents and subsequent project plans Provides high-level project direction, receives project status updates, and addresses and resolves issues, risks, or change requests
- 11. 10 6.3 Project Organizational Charts The following RACI chart shows the relationship between project tasks and team members. Any proposed changes to project responsibilities must be reviewed and approved by the project manager. Changes will be proposed in accordance with the project’s change control process. As changes are made all project documents will be updated and redistributed accordingly. Roles PM Designer Programmer Training Leads QA Testing Specialist Technical write Project Sponsor Steering Committee Requirements Gathering A R R C R C I C I Design A R C C I I C I Coding A R R I I I Testing A C C R R I I C Implementation A R C I C C I C Conduct Training A R C C I I C Documentation A C R I C Key: R – Responsible for completing the work A – Accountable for ensuring task completion/sign off C – Consulted before any decisions are made I – Informed of when an action/decision has been made
- 12. 11 6.4 Staffing Management Staff Acquisition: For the Researchcolab.com Project the project staff will consist entirely from IIT Software Project Management class. The Project Manager will form the project team in order to identify and assign resources. All resources including the project manager must be approved by the course teacher before the resource may begin any project work. Resource Calendars: The Researchcolab.com Project is scheduled to last 3 months with 7 hours/persons per week. The Project will require all project team members for the entire duration of the project. Training: There is currently no training scheduled with regards to the Researchcolab.com Project since the project team has adequate staff (7 members) with required skill sets. However, if training requirements are identified or there is a need for recreational activities, funding will be provided from the project reserve. 7. Procurement Management This Procurement Management Plan sets the procurement framework for this project. It will serve as a guide for managing procurement throughout the life of the project and will be updated as acquisition needs change. This plan identifies and defines the items to be procured, the types of contracts to be used in support of this project, the contract approval process, and decision criteria. 7.1 Procure Management Approach The Project Manager will provide oversight and management for all procurement activities under this project. The Project Manager will work with the project team to identify all items to be procured for the successful completion of the project. The Project Management will then review the procurement list prior to submitting it for contracts and purchasing. The management will review the procurement items, determine whether it is advantageous to make or buy the items, and begin the vendor selection, purchasing and the contracting process.
- 13. 12 7.2 Procurement Definition The following procurement items have been determined to be essential for project completion and success. Item/Services Justification Needed By Laptop, 7 Pcs Needed for the project staffs to start their works 31 July, 2016 Desktop Computer, 3 Pcs Needed for the developers to start the main development works 15 August, 2016 Internet Connectivity Needed for R&D and communication 31st July, 2016 In addition to the above list of procurement items, the following individuals are authorized to approve purchases for the project team: Name Role Adiluzzaman Adil Project Manager 7.3 Type of Contract to be used All items and services to be procured for this project will be solicited under firm-fixed price contracts. The management will then solicit bids from various vendors in order to procure the items within the required time frame and at a reasonable cost under the firm fixed price contract once the vendor is selected. 7.4 Procurement Risks All procurement activities carry some potential for risk which must be managed to ensure project success. While all risks will be managed in accordance with the project’s risk management plan, there are specific risks which pertain specifically to procurement which must be considered: - Unrealistic schedule and cost expectations for vendors - Supply capacity capabilities of vendors - Configuration management for upgrades and improvements of purchased technology - Potential delays in shipping and impacts on cost and schedule - Questionable past performance for vendors - Potential that final product does not meet required specifications These risks are not all-inclusive and the standard risk management process of identifying, documenting, analyzing, mitigating, and managing risks will be used. 7.5 Procurement Risk Management As previously stated, project risks will be managed in accordance with the project’s risk management plan. However, for risks related specifically to procurement, there must be additional consideration and involvement. Project procurement efforts involve external organizations and
- 14. 13 potentially affect current and future business relationships as well as internal supply chain and vendor management operations. Because of the sensitivity of these relationships and operations the project team will include the project sponsor and a designated representative from the contracting department in all project meetings and status reviews. 7.6 Cost Determination For this project we will issue a Request for Proposal (RFP) in order to solicit proposals from various vendors which describe how they will meet our requirements and the cost of doing so. All proposals will include vendor support for items A, B, and C (from procurement definition paragraph) as well as the base and out-year costs. The vendors will outline how the work will be accomplished, who will perform the work, vendors’ experience in providing these goods, customer testimonials, backgrounds and resumes of employees performing the work, and a line-item breakdown of all costs involved. Additionally, the vendors will be required to submit work breakdown structures (WBSs) and work schedules to show their understanding of the work to be performed and their ability to meet the project schedule. All information must be included in each proposal as the proposals will be used as the foundation of our selection criteria. Proposals which omit solicited information or contain incomplete information will be discarded from consideration. 7.7 Procurement Constraints There are several constraints that must be considered as part of the project’s procurement management plan. These constraints will be included in the RFP and communicated to all vendors in order to determine their ability to operate within these constraints. These constraints apply to several areas which include schedule, cost, scope, resources, and technology: Schedule: Project schedule is not flexible and the procurement activities, contract administration, and contract fulfillment must be completed within the established project schedule. Cost: Project budget has contingency and management reserves built in; however, these reserves may not be applied to procurement activities. Reserves are only to be used in the event of an approved change in project scope or at management’s discretion. Scope: All procurement activities and contract awards must support the approved project scope statement. Any procurement activities or contract awards which specify work which is not in
- 15. 14 direct support of the project’s scope statement will be considered out of scope and disapproved. Resources: All procurement activities must be performed and managed with current personnel. No additional personnel will be hired or re-allocated to support the procurement activities on this project. Technology: Parts specifications have already been determined and will be included in the statement of work as part of the RFP. While proposals may include suggested alternative material or manufacturing processes, parts specifications must match those provided in the statement of work exactly. 7.8 Contract Approval Process The first step in the contract approval process is to determine what items or services will require procurement from outside vendors. This will be determined by conducting a cost analysis on products or services which can be provided internally and compared with purchase prices from vendors. Once cost analyses are complete and the list of items and services to be procured externally is finalized, the purchasing and contracts department will send out solicitations to outside vendors. Once solicitations are complete and proposals have been received by all vendors the approval process begins. The first step of this process is to conduct a review of all vendor proposals to determine which meet the criteria established by the project team and the management. Purchases less than BDT 50,000/= only require the approval of the Project Manager; whereas, purchases greater than BDT 50,000/= must be approved by the management. For these larger purchases the management will meet to determine which contract will be accepted. 7.9 Decision Criteria The criteria for the selection and award of procurement contracts under this project will be based on the following decision criteria: - Ability of the vendor to provide all items by the required delivery date - Quality - Cost - Expected delivery date - Comparison of outsourced cost versus in-sourcing - Past performance These criteria will be measured by the contracts review board and/or the Project Manager. The ultimate decision will be made based on these criteria as well as available resources.
- 16. 15 7.10 Vendor Management The Project Manager is ultimately responsible for managing vendors. In order to ensure the timely delivery and high quality of products from vendors the Project Manager will meet weekly with each vendor to discuss the progress for each procured item. The meetings can be in person or by teleconference. The Project Manager will be responsible for scheduling this meeting on a weekly basis until all items are delivered and are determined to be acceptable. 8. Risk Management Risk is inevitable in a business organization when undertaking projects. However, the project manager needs to ensure that risks are kept to a minimal. Risks can be mainly divided between two types, negative impact risk and positive impact risk. The project manager will plan their strategy based on four steps: Risk Identification Risk Quantification Risk Response Risk Monitoring and Control 8.1 Risk Identification The category of risks identification is listed below- 1. General Risk: a) The project may not be completed within deadline b) The project may fail to maintain its budget c) Poor project planning d) Academic study may hinder the progress of this project e) Project milestones are not defined clearly f) Ineffective project management g) Monitoring the progress of this project is not done properly h) Inadequate estimation of required resources i) Poor communication among the project members j) Individual member might fail to meet his/her deadline.
- 17. 16 2. Subject oriented risk: i. Development oriented – a. Developers do not have the specialized skills needed for this project b. Insufficient knowledge about the new technology required by the project c. The technology used in the project is outdated ii. Testing oriented – a. The testing of this project might not be done properly iii. Design oriented – a. The problem can exist in the design phase iv. Quality control oriented – a. The quality of the project is not up to mark b. The system may fail during its execution 8.3 Risk Qualification and Prioritization In order to determine the severity of the risks identified by the team, a probability and impact factor was assigned to each risk. This process allowed the project manager to prioritize risks based upon the effect they may have on the project. The project manager utilized a probability-impact matrix to facilitate the team in moving each risk to the appropriate place on the chart. Once the risks were assigned a probability and impact and placed in the appropriate position on the chart, the recorder captured the finished product and the project manager moved the process on to the next step: risk mitigation/avoidance planning. 8.4 Risk Monitoring Regular monitoring and review of risks is an important part of the ReasearchColab program. It ensures that new risks are; detected; added to the Risk Register, managed and that action plans are implemented and progressed effectively. The ReasearchColab monitoring and review strategies include:- Risk management will be a stander topic of discussion in the monthly board project meeting. This agenda will cover the review of risk register and its update information. The Project Manager will monitor day-to-day progression of Risk Management Action plans.
- 18. 17 8.5 Risk Mitigation and Avoidance The project manager has led the project team in developing responses to each identified risk. As more risks are identified, they will be qualified and the team will develop avoidance and mitigation strategies. These risks will also be added to the Risk Register and the project plan to ensure they are monitored at the appropriate times and are responded to accordingly. The risks for this project will be managed and controlled within the constraints of time, scope, and cost. All identified risks will be evaluated in order to determine how they affect this triple constraint. The project manager, with the assistance of the project team, will determine the best way to respond to each risk to ensure compliance with these constraints. In extreme cases it may be necessary to allow flexibility to one of the project’s constraints. Only one of the constraints for this project allows for flexibility as a last resort. If necessary, funding may be added to the project to allow for more resources in order to meet the time (schedule) and scope constraints. Time and scope are firm constraints and allow for no flexibility. Again, the cost constraint is flexible only in extreme cases where no other risk avoidance or mitigation strategy will work. 8.6 Risk Register The Risk Register for this project is a log of all identified risks, their probability and impact to the project, the category they belong to, mitigation strategy, and when the risk will occur. The register was created through the initial project risk management meeting led by the project manager. During this meeting, the project team identified and categorized each risk. Additionally, the team assigned each risk a score based on the probability of it occurring and the impact it could potentially have. The Risk Register also contains the mitigation strategy for each risk as well as when the risk is likely to occur. Based on the identified risks and timeframes in the risk register, each risk has been added to the project plan. At the appropriate time in the plan—prior to when the risk is most likely to occur— the project manager will assign a risk manager to ensure adherence to the agreed upon mitigation strategy. The each risk manager will provide the status of their assigned risk at the bi-weekly project team meeting for their risk’s planned timeframe. Severity and likelihood of the risks will be scaled in the following ways- Categorized Harm Severity Severity Level Risk Normal 1 Very Low Negligible 2 Low Marginal 3 Moderate Critical 4 High Catastrophic 5 Extreme
- 19. 18 The likelihood category will be defined as follows: Likelihood Category Likelihood Level Less Likely 1 Likely 2 Very Likely 3 9. Configuration Management In order to effectively manage the Reserchcolab.com Project, a coordinated Configuration Management (CM) Plan is needed. This plan will establish CM roles and responsibilities and describe how the Reserchcolab.com Project team will track, implement, and communicate configuration items (CIs) and changes throughout the project lifecycle. 9.1 Roles and Responsibilities The following roles and responsibilities involve to the CM Plan for Researchcolab.com Project. Configuration Control Board (CCB) The CCB is comprised of the Researchcolab.com Project Sponsor, Project Manager and Quality Assurer. The CCB is responsible for the following: Review and approve/reject configuration change requests Ensure all approved changes are added to the configuration management log. Seeking clarification on any CIs as required Project Manager The Project Manager is responsible for: Overall responsibility for all CM activities related to the Researchcolb.com project Identification of CIs All communication of CM activities to project team Participation in CCB meetings Re-baselining, if necessary, any items affected by CM changes
- 20. 19 Quality assurer The Configuration Manager is responsible for: Overall management of the Configuration change Identification of CIs Providing configuration standards and templates to the project team All identified CIs will be assigned to a right job. Ensure all change requests comply with change request templates and standards prior to the CCB 9.2 Configuration Control The Researchcolab.com Project will use a standardized configuration control process throughout the project lifecycle in order to ensure all CIs are handled in a consistent manner and any approved changes are fully reviewed regarding impact and communicated to project team. Any configuration changes which are identified by the project team must be captured in a configuration change request (CCR) and submitted to the CCB. The CCB will review, analyze, and approve/deny the request based on the impact, scope, time, and cost of the proposed change. If the change is approved, the project requirements will be re-baselined (if necessary) and all changes will be communicated to the project team and stakeholders by the Project Manager. Denied CCRs may be re-submitted with additional or new information for re-consideration by the CCB. As CIs are identified by the project team, the Configuration Manager will assign a CI name and the CI will be then assigned to the concern person. It is necessary that for any software changes, testing is conducted by the testing specialist in order to validate any changes made. 9.3 Configuration Status Accounting It is important that for the Researchcolab.com Project and the Project Sponsor have the ability to review configuration status at any given time. The Project Manager will also submit weekly reports, to include configuration status, every Saturday. These reports will consist of the following information as part of the configuration status section:
- 21. 20 1) Change requests a. Aging - How long change requests have been open b. Distribution – number of change requests submitted by project team c. Trending – what area(s) are approved changes occurring in 2) Version Control a. Software b. Hardware c. Data d. Documentation 3) Build Reporting a. Files b. CI relationships c. Incorporated Changes Prior to the final implementation, the CM will work with project team to ensure all CIs are updated with latest release versions. 9.4 Change Request Form Name and location of Individual Submitting Request Machine ID Date and time Type of Change Request (i.e. software, hardware, problem report)
- 22. 21 Description of the Change Requested Is this an “Error” or “Enhancement?” Severity Level H: Hinder Operations. No Work Around exists. HM: Hinder Operations. An acceptable Work Around exists ML: Does not hinder operations. No acceptable Work Around exists. L: Does not hinder operations. An acceptable Work Around exists. Date Needed Who developed and is maintaining the application Name of application Is this a Software or Hardware modification? Operational Context What was occurring when this happened? How can this be recreated (if possible)? Describe the frequency of occurrence.
- 23. 22 10. Communication Plan This Communications Management Plan sets the communications framework for this project. It will serve as a guide for communications throughout the life of the project and will be updated as communication needs change. This plan identifies and defines the roles of persons involved in this project. It also includes a communications matrix which maps the communication requirements of this project. 10.1 Communications Management Approach The Project Manager will take a proactive role in ensuring effective communications on this project. The communications requirements are documented in the Communications Matrix presented in this document. The Communications Matrix will be used as the guide for what information to communicate, who is to do the communicating, when to communicate it and to whom to communicate. As with most project plans, updates or changes may be required as the project progresses or changes are approved. Changes or updates may be required due to changes in personnel, scope, budget, or other reasons. Additionally, updates may be required as the project matures and additional requirements are needed. The project manager is responsible for managing all proposed and approved changes to the communications management plan. Once the change is approved, the project manager will update the plan and supporting documentation and will distribute the updates to the project team and all stakeholders. This methodology is consistent with the project’s Change Management Plan and ensures that all project team members/stakeholders remain aware and informed of any changes to communications management. 10.2 Communications Management Constraints All project communication activities will occur within the project’s approved budget, schedule, and resource allocations. The project manager is responsible for ensuring that communication activities are performed by the project team and without external resources which will result in exceeding the authorized budget. Communication activities will occur in accordance with the frequencies detailed in the Communication Matrix in order to ensure the project adheres to
- 24. 23 schedule constraints. Any deviation of these timelines may result in excessive costs or schedule delays and must be approved by the project sponsor. 10.3 Stakeholder Communication Requirements As part of identifying all project stakeholders, the project manager will communicate with each stakeholder in order to determine their preferred frequency and method of communication. Standard project communications will occur in accordance with the Communication Matrix; however, depending on the identified stakeholder communication requirements, individual communication is acceptable and within the constraints outlined for this project. In addition to identifying communication preferences, stakeholder communication requirements must identify the project’s communication channels and ensure that stakeholders have access to these channels. If project information is communicated via secure means or through internal project resources, all stakeholders must have the necessary access to receive project communications. 10.4 Roles Project Sponsor The project sponsor is the champion of the project and has authorized the project by signing the project charter. This person is responsible for the funding of the project and is ultimately responsible for its success. Since the Project Sponsor is at the executive level, communications should be presented in summary format unless the Project Sponsor requests more detailed communications. Stakeholders Normally Stakeholders includes all individuals and organizations who are impacted by the project. For this project, we are defining the stakeholders with whom we need to communicate with and are not included in the other roles defined in this section. The stakeholders include executive management with an interest in the project and key users identified for participation in the project. Customer
- 25. 24 The customer for this project is the Software Project Management course teacher, Ajmal Huda. As the customer who will be accepting the final deliverable of this project, he will be informed of the project status including potential impacts to the schedule for the final deliverable and the product itself. Project Manager The Project Manager has overall responsibility for the execution of the project. The Project Manager manages day to day resources, provides project guidance and monitors and reports on the project. The Project Manager is the primary communicator for the project distributing information according to this Communications Management Plan. Project Team The Project Team is comprised of all persons who have a role performing work on the project. The project team needs to have a clear understanding of the work to be completed and the framework in which the project is to be executed. Since the Project Team is responsible for completing the work for the project they played a key role in creating the Project Plan including defining its schedule and work packages. The Project Team requires a detailed level of communications which is achieved through day to day interactions with the Project Manager and other team members along with weekly team meetings. Technical Lead The Technical Lead is a person on the Project Team who is designated to be responsible for ensuring that all technical aspects of the project are addressed and that the project is implemented in a technically sound manner. The Technical Lead is responsible for all technical designs, overseeing the implementation of the designs and developing as-build documentation. The Technical Lead requires close communications with the Project Manager and the Project’s other Team members.
- 26. 25 10.5 Communication Methods and Technologies The project team will determine the communication methods and technologies based on several factors to include: stakeholder and project’s team members’ communication requirements and available technologies. Researchcolam.com project maintains a Shared web platform, a closed group account on Facebook which all project team members use to provide updates, archive various documents, access project data and conduct project communications at any point in time. This shared web platform also provides the ability for stakeholders and project team members to collaborate on project work and communication.
- 27. 26 10.6 Communications Matrix The following table identifies the communications requirements for Researchcolab.com project. Communication Type Objective of Communication Medium Frequency Audience Owner Deliverable Format Kickoff Meeting Introduce the project team and the project. Review project objectives and management approach. Face to Face Once Project Team Stakeholders Project Manager Agenda Meeting Minutes Soft copy archived on project Shared web site Project Team Meetings Review status of the project with the team. Face to Face Conference Call Weekly Project Team Project Manager Agenda Meeting Minutes Project schedule Soft copy archived on project Shared web site Technical Design Meetings Discuss and develop technical design solutions for the project. Face to Face As Needed Project Technical Staff Designer Agenda Meeting Minutes Soft copy archived on project Shared web site Weekly Project Status Presentation Report on the status of the project to course teacher Power Point Presentation Weekly Course Teacher Other project teams Project Manager Power Point Slide updates Soft copy archived on project Shared web site Project Status Reports Report the status of the project including activities, progress, costs and issues. Email Monthly Project Sponsor Project Team Stakeholders Course Teacher Project Manager Project Status Report Project schedule Soft copy archived on project Shared web site
- 28. 27 10.7 Guidelines for Meetings Meeting Agenda Meeting Agenda will be decided 5 working days in advance of the meeting. The Agenda should identify the team member for each topic. The first item in the agenda should be a review of action items from the previous meeting. Meeting Minutes Meeting minutes will be uploaded on the project’s web site within 1 business days following the meeting by project manager. Meeting minutes will include the status of all items from the agenda along with new action items. Action Items Action Items are recorded in both the meeting agenda and minutes. Action items will include both the action item along with the owner of the action item. Meetings will start with a review of the status of all action items from previous meetings and end with a review of all new action items resulting from the meeting. The review of the new action items will include identifying the owner for each action item. 11. Change Management The Change Management Plan is created for the Researchcolab.com Project in order to set expectations on how the approach to changes will be managed, what defines a change, the purpose and role of the change control board, and the overall change management process. All stakeholders will be expected to submit or request changes to the Researchcolab.com Project in accordance with this Change Management Plan and all requests and submissions will follow the process detailed herein. 11.1 Change Management Approach The Change Management approach for the Researchcolab.com Project will ensure that all proposed changes are defined, reviewed, and agreed upon so they can be properly implemented
- 29. 28 and communicated to all stakeholders. This approach will also ensure that only changes within the scope of this project are approved and implemented. The Change Management approach consists of three areas: Ensure changes are within scope and beneficial to the project Determine how the change will be implemented Manage the change as it is implemented The Change Management process has been designed to make sure this approach is followed for all changes. By using this approach methodology, the Researchcolab.com Project Team will prevent unnecessary change from occurring and focus its resources only on beneficial changes within the project scope. 11.2 Definitions of Change There are several types of changes which may be requested and considered for the Researchcolab.com Project. Depending on the extent and type of proposed changes, changes project documentation and the communication of these changes will be required to include any approved changes into the project plan and ensure all stakeholders are notified. Types of changes include: Scheduling Changes: changes which will impact the approved project schedule. These changes may require fast tracking, crashing, or re-baselining the schedule depending on the significance of the impact. Budget Changes: changes which will impact the approved project budget. These changes may require requesting additional funding, releasing funding which would no longer be required, or adding to project or management reserves. May require changes to the cost baseline. Scope Changes: changes which are necessary and impact the project’s scope which may be the result of unforeseen requirements which were not initially planned for. These changes may also impact budget and schedule. These changes may require revision to WBS, project scope statement, and other project documentation as necessary.
- 30. 29 The project manager must ensure that any approved changes are communicated to the project stakeholders. Additionally, as changes are approved, the project manager must ensure that the changes are captured in the project documentation where necessary. These document updates must then be communicated to the project team and stakeholders as well. 11.3 Change Control Board The Change Control Board (CCB) is the approval authority for all proposed change requests pertaining to the Researchcolab.com Project. The purpose of the CCB is to review all change requests, determine their impacts on the project risk, scope, cost, and schedule, and to approve or deny each change request. The following chart provides a list of the CCB members for the Researchcolab.com Project: Name Position CCB Role Md. Adiluzzaman Adil Project Manager CCB Manager Kishan kumar Ganguly Md. Rakib Hossain Software Architect & Developer CCB Member Minhas Kamal A.H.M. Azimul Haque Designer & Developer CCB Member Mostaque Ahmed Israt Fatema Shantu Documentation CCB Member As change requests are submitted to the Researchcolab.com Project Manager by the project team/stakeholders, the Project Manager will log the requests in the change log and the CCB will convene every other Saturday to review all change requests. For a change request to be approved, all CCB members must vote in favor. In the event, more information is needed for a particular change request, the request will be deferred and sent back to the requestor for more information or clarification. If a change is deemed critical, an ad hoc CCB meeting can be called in order to review the change prior to the next scheduled bi-weekly CCB meeting.
- 31. 30 11.4 Roles and Responsibilities The following are the roles and responsibilities for all change management efforts related to the Researchcolab.com Project: Project Sponsor: Approve all changes to budget/funding allocations Approve all changes to schedule baseline Approve any changes in project scope Chair the CCB Project Manager: Receive and log all change requests from project stakeholders Conduct preliminary risk, cost, schedule, scope analysis of change prior to CCB Seek clarification from change requestors on any open issues or concerns Make documentation revisions/edits as necessary for all approved changes Participate on CCB Project Team/Stakeholders: Submit all change requests on change request forms Provide all applicable information and detail on change request forms Be prepared to address questions regarding any submitted change requests Provide feedback as necessary on impact of proposed changes 11.5 Change Control Process The Change Control Process for the Researchcolab.com Project will follow the organizational standard change process for all projects. The project manager has overall responsibility for executing the change management process for each change request. 1) Identify the need for a change (Stakeholders) – Change requestor will submit a completed change request form to the project manager. 2) Log change in the change request register (Project Manager) – The project manager will keep a log of all submitted change requests throughout the project’s lifecycle.
- 32. 31 3) Evaluate the change (Project Manager, Team, and Requestor) – The project manager will conduct a preliminary analysis on the impact of the change to risk, cost, schedule, and scope and seek clarification from team members and the change requestor. 4) Submit change request to CCB (Project Manager) – The project manager will submit the change request, as well as the preliminary analysis, to the CCB for review. 5) Obtain Decision on change request (CCB) – The CCB will discuss the proposed change and decide whether or not it will be approved based on all submitted information. 6) Implement change (Project Manager) – If a change is approved by the CCB, the project manager will update and re-baseline project documentation as necessary. 11.6 Change Management Log Following instructions are followed for capturing change requests in the project- Column Instructions for Completing Change Request Document A ID: A unique ID number used to identify the change request in the change management tracking log. B Current Status: This column should be populated with the change request's current status. o Open: The change request is currently open but has not yet been addressed. o Work In Progress: The change request is being actively worked to develop a resolution. o Closed: The change request is no longer considered an active project threat and can be closed with or without resolution. Some other potential options include: o Late: The change request resolution is not yet resolved and it is past the expected resolution date. o On Hold: The change request has been put on hold. o Combined: Two change requests found to be similar have been combined. C Priority: This column should be populated with the priority of the change request. Valid options include the following: Critical, High, Medium and Low. These are defined as follows: o Critical: change request will stop project progress if not resolved. o High: change request will likely move the project back in terms of budget or timeline, or will materially affect quality or scope. o Medium: change request will have material effect on project, has potential to be moved to high category and/or requires significant resources to manage. o Low: change request is expected to have a moderate effect on the project, but will require resources to address.
- 33. 32 D Change Request Description: This column should be populated with a description of the change request. E Assigned to Owner: This column should be populated with the name of the change requests owner. The individual most responsible for working towards resolving the change request. F Expected Resolution Date: This column should be populated with the date that the change request is expected to be resolved. G Escalation Required (Y/N): This column should be populated with “Yes” if the change request needs to be escalated and “No” if escalation is not needed to resolve the change request. H Action Steps: This column should be populated with the proposed steps to address the change request. Examples include, but are not limited to, developing alternatives analysis or submitting a change request. I Impact Summary: This column should be populated with a description of the impact of the change request. The impact may be expressed in terms of one or more of the following: schedule, scope, resources, and space. The impact description should also include a reference to any milestones impacted. J Change Request Type: This column should be populated with the change request type. Valid options include the following: Product, Project, Other. These are defined as follows: o Product: The change request impacts the products being developed. o Project: The change request impacts the project developing the product. o Other: The change request impacts other areas. K Date Identified: This column should be populated with the date that the change request was identified. L Associated ID(s): This column should contain the project ID of any associated milestones that may be impacted by a change request or that the change request is dependent upon for resolution. M Entered By: This column should be populated with the name of the individual who first identified the change request. N Actual Resolution Date: This column should be populated with the date that the change request was actually resolved. O Final Resolution & Rationale: This column should be populated with a description of the final resolution of and rationale for the change request. The resolution may be expressed in terms of one or more of the following: schedule, scope, resources, and space. The resolution description should also include a reference to the milestones impacted.
- 34. 33 11.7 Change Management log format PROJECT NAME: RESEARCHCOLAB.COM PROJECT MANAGER NAME: ID CURRENT STATUS PRIORITY CHANGE REQUEST DESCRIPTION ASSIGNED TO OWNER EXPECTED RESOLUTION DATE ESCALATION REQUIRED Y/N ACTION STEPS IMPACT SUMMERY CHANGE REQUEST TYPE ACTUAL RESOLUTION DATE FINAL RESOLUTION & RATIONALE 1 2 3 12. Quality Assurance The Quality Management Plan for the Researchcolab.com project will establish the activities, processes, and procedures for ensuring a quality product upon the conclusion of the project. The purpose of this plan is to: Ensure quality is planned Define how quality will be managed Define quality assurance activities Define quality control activities Define acceptable quality standards 12.1 Quality Management Approach The quality management approach for the Researchcolab.com project will ensure quality is planned for both the project deliverables and processes. In order to be successful, this project will meet its quality objectives by utilizing an integrated quality approach to define quality standards, measure quality and continuously improve quality. The quality management plan identifies these key components: Objects of quality review Quality Measure Quality Evaluation Methods Project Deliverables Deliverable Quality Standards Completeness and Correctness Criteria Quality Control Activities Project Processes Process Quality Standards Stakeholder Expectations Quality Assurance Activities
- 35. 34 The following is a brief explanation of each of the components of the quality management plan. Project Deliverables and Processes The key project deliverables and processes subject to quality review. Deliverable Quality Standards and Completeness and Correctness Criteria The quality standards that are the “measures” used to determine a successful outcome for a deliverable. The completeness and correctness criteria describe when each deliverable is complete and correct as defined by the customer. Deliverables are evaluated against these criteria before they are formally approved. Process Quality Standards and Stakeholder Expectations The quality standards that are the “measures” used to determine if project work processes are being followed. Stakeholder expectations describe when a project process is effective as defined by the project stakeholders. An example is the expectation to be regularly informed monthly of project status. Quality Control Activities The quality control activities that monitor and verify that the project deliverables meet defined quality standards. Quality Assurance Activities The quality assurance activities that monitor and verify that the processes used to manage and create the deliverables are followed and are effective. Quality improvements will be identified by any member of the project team or quality assurer. Each recommendation will be reviewed to determine the cost versus benefit of implementing the improvement and how the improvement will impact the deliverables or processes. If an improvement is implemented the project manager will update all project documentation to include the improvement and the quality manager will update the organizational documentation the improvement affects. 12.2 Quality Requirements / Standards Product Quality: The product quality standards and requirements will be determined by the project team and quality assurer. These standards will primarily be based on the project teams’ identified documented
- 36. 35 standards for web based platform. There may be product-specific quality standards identified that are not currently part of the documented standards. In this case, the quality assurer will review these newly identified standards and incorporate them into project documentation if approved. The project team will also document any newly identified quality standards into the Researchcolab.com project plan and ensure communication with all team members/stakeholders. Process Quality: The process quality standards and requirements will be determined by the project team and quality assurer. Many of these standards will be based on existing website process standards. However, it is anticipated that there will be several unique steps in the developing of the Researchcolab.com project which will require new quality standards. The Researchcolab.com project team will work with the quality assurer to establish acceptable standards and document these standards for incorporation into Researchcolab.com project plan. These standards will be communicated to all project team members/stakeholders. 12.3 Quality Assurance The quality assurance of the Researchcolab.com Project focuses on the processes used in the developing of the web based platform. In order to ensure quality, an iterative quality process will be used throughout the project life cycle. The Researchcolab.com Project Manager and the project team will perform assessments at planned intervals throughout the project to ensure all processes are being correctly implemented and executed. The table below provides the key quality assurance activities for the Researchcolab.com Project: Activity Coverage Description Preconditions Every public method Use if-statements at the beginning of public methods to validate each argument value. This helps to document assumptions and catch invalid values before they can cause faults. Assertions Every private method Assertions will be used to validate all arguments to private methods. Since these methods are only called from our other methods, arguments passed to them should always be valid, unless our code is defective. Assertions will also be used to test class invariants and some post-conditions.
- 37. 36 Review meetings Weekly, once before release, every source file In these reviews, an agenda item will include a review of project processes, any inconsistency and/or audit findings from the Quality assurer, and a discussion on process improvement initiatives. Unit testing 100% of public methods, 75% of statements, 100% of public methods, 75% of statements We will develop and maintain a unit test suite using the JUnit framework. We will consider the boundary conditions for each argument and test both sides of each boundary. Tests must be run and passed before each commit, and they will also be run by the testing team. Each public method will have at least one test. And, the overall test suite will exercise at least. 75% of all executable statements in the system Manual system testing 100% of UI screens and fields, 100% of specified requirements The QA team will author and maintain a detailed written suite of manual tests to test the entire system through the user interface. This plan will be detailed enough that a person could repeatedly carry out the tests from the test suite document and other associated documents Regression testing Run all unit tests before each commit, run all unit tests nightly We will use selenium tool to frequently rerun all automated tests, including those that have previously been successful. This will help catch regressions (bugs that we thought were fixed, but that appear again). Load, stress, and capacity testing. Simple load testing, detailed analysis of each scalability parameter. Use Apache JMeter tool to test load, stress and capacity of the system. Process improvement Weekly Quality assurance reviews, findings, and assessments should always result in some form of process improvement and, as a result, product improvement. All process improvement efforts must be documented, implemented, and communicated to all stakeholders as changes are made. 12.4 Quality Control Measurements All Researchcolab.com Project products and processes must be measured and fall within the established standards and tolerances. The below logs will be used by the project and quality teams in conducting these measurements and will be maintained for use as supporting documentation for the project’s acceptance.
- 38. 37 Quality Assurance Log ID # Date Process Measured Required Value Actual Measured Acceptable? (Y/N) Recommendation Date Resolved Quality Control Log ID # Date Deliverables Measured Required Value Actual Measured Acceptable? (Y/N) Recommendation Date Resolved 13. Release The project release contains the following deliverables: Deliverable Description Date Project Management Reports This deliverable describes about the entire project plan. It contains which development process to follow, how to coordinate between team members, which development tools to follow. 15th August, 2016 SRS & Design document The architecture of the software and UX design is described in this report. 25th October, 2016 Configuration Manual Configuration Manual describes about how to configure the tools and what environment is required for running the software. 20th November, 2016 Executable code module The actual tool will be provided. 26th November, 2016
- 39. 38 14. Budget The Project Manager will be responsible for managing and reporting on the project’s cost throughout the duration of the project. During the monthly project status meeting, the Project Manager will meet with project team to present and review the project’s cost performance for the preceding month. Performance will be measured using earned value. The Project Manager is responsible for accounting for cost deviations and presenting the Project Sponsor with options for getting the project back on budget. The Project Sponsor has the authority to make changes to the project to bring it back within budget. 14.1 Measuring Project Costs Performance of the project will be measured using Earned Value Management. The following four Earned Value metrics will be used to measure to projects cost performance: Schedule Variance (SV) Cost Variance (CV) Schedule Performance Index (SPI) Cost Performance Index (CPI) If the Schedule Performance Index or Cost Performance Index has a variance of between 0.1 and 0.2 the Project Manager must report the reason for the exception. If the SPI or CPI has a variance of greater than 0.2 the Project Manager must report the reason for the exception and provide management a detailed corrective plan to bring the projects performance back to acceptable levels. Performance Measure Yellow Red Schedule Performance Index (SPI) Between 0.9 and 0.8 or Between 1.1 and 1.2 Less Than 0.8 or Greater than 1.2 Cost Performance Index (CPI) Between 0.9 and 0.8 or Between 1.1 and 1.2 Less Than 0.8 or Greater than 1.2 14.2 Reporting Format Reporting for cost management will be included in the monthly project status report. The Monthly Project Status Report will include a section labeled, “Cost Management”. This section will contain the Earned Value Metrics identified in the previous section. All cost variances outside of the thresholds identified in this Cost Management Plan will be reported on including any corrective actions which are planned. Change Requests which are triggered based upon project cost overruns will be identified and tracked in this report.
- 40. 39 14.3 Cost Variance Response Process The Control Thresholds for this project is a CPI or SPI of less than 0.8 or greater than 1.2. If the project reaches one of these Control Thresholds a Cost Variance Corrective Action Plan is required. The Project Manager will present the Project Sponsor with options for corrective actions within five business days from when the cost variance is first reported. Within three business days from when the Project Sponsor selects a corrective action option, the Project Manager will present the Project Sponsor with a formal Cost Variance Corrective Action Plan. The Cost Variance Corrective Action Plan will detail the actions necessary to bring the project back within budget and the means by which the effectiveness of the actions in the plan will be measured. Upon acceptance of the Cost Variance Corrective Action Plan it will become a part of the project plan and the project will be updated to reflect the corrective actions. 14.4 Cost Change Control Process The cost change control process will follow the established project change request process. Approvals for project budget/cost changes must be approved by the project sponsor. 14.5 Project Budget The cost estimation is the approximation of the cost related to a project or operation. This project includes the cost of – 1. Opex 2. Capex 1. Opex: Opex consists of all the operational costs. They include- Working hour Logistic support Utility Miscellaneous Work hour breakdown Total persons working 7 Work hour per person per day 1 Total working days 60 Total work hours per person 60 Work hours in total 420
- 41. 40 Logistic support needed 1. Transport cost 2. Report printing 3. Web Hosting Utility necessity 1. Internet bill Miscellaneous 1. Contingency 2. Capex: The capital expenditure for this project only consists of the laptop and desktop computers used for the development of this project. A breakdown of the total cost for the project Type Sector Breakdown Frequency Amount (BDT) Opex Project staffing Total work hours 420 Daily 63,000/= BDT Cost per person per hour 150/= BDT Logistic Transport 1,000/= BDT Ongoing 11,500/= BDTReport Printing 1,500/= BDT Web hosting 9,000/= BDT Utility Internet bills (7 person, 2 months) 7,000/= BDT Ongoing 7,000/= Miscellaneous Ongoing 2,000/= Capex Laptop Laptop computers 7 Pcs One time 2,80,000/= Desktop Desktop computers 3 Pcs One time 1,20,000/= Premises Ongoing 2,40,000/= Total anticipated costs 7,23,500 /=