Assignment 01 Starting week: 06 Due Week: 08 Assignment Goals: On completion of this assignment, you should be able to,

Identify Work Breakdown Structure Draw a project plan Analyze and document project risks

Problem: You are hired as a project manager to handle a project at a printing organization. The organization is involved in automating their order processing system. The required system needs to handle customer orders placed by the customer care officers and those placed orders are processed by back office staff. The proposed system should be able to connect with their newly purchased high tech printing machine and it will automatically provide the status of each order. Also once an order is processed the machine will update the system automatically. You need to gather requirements and develop a computer system in order to automate the said organization. You are given 1 business analyst, 2 software engineers and 3 trainee software engineers. Except for one software engineer others have not done similar kind of project and neither do you have any experience in handling this kind of automation project. Training should be given to 3 trainee software engineers in order to get output from them. Integrating with the printing machine is a critical part in this project and no one has done a similar integration earlier. The project owner is the CEO of the organization he has no IT experience and users in this organization have not worked in an automated system. The owner plans to get large orders from some companies to print their annual reports. He applies pressure to finish the project within 6 months. Assessment criteria: (Total 100%)

Preparation of Work Breakdown Structure (WBS) 20% Listing of risks involve in this project 20% Drawing of grant chart 20% Planning suitable requirement gathering techniques 20% Report presented using a word processing software (e.g. MS Word) 10% Formatting of the Report 10%

1. Preparation of Work Breakdown Structure (WBS) 20% 1. Scope 1.1. Determine project scope 1.2. Proposal Writing 1.3.Cost Estimation and Cost Benefit Analysis 1.4. Secure core resources 1.5. Scope complete 2. Analysis/Software Requirements 2.1. Conduct needs analysis 2.2. Draft preliminary software specifications 2.3. Develop preliminary budget 2.4. Review software specifications/budget with team 2.5. Incorporate feedback on software specifications 2.6. Develop delivery timeline 2.7. "Obtain approvals to proceed (concept, timeline, budget)" 2.8. Secure required resources 2.9. Analysis complete 3. Design 3.1. Review preliminary software specifications 3.2. Develop functional specifications 3.3. Develop prototype based on functional specifications 3.4. Review functional specifications 3.5. Incorporate feedback into functional specifications 3.6. Obtain approval to proceed 3.7. Design complete 4. Development 4.1. Review functional specifications 4.2. Identify modular/tiered design parameters 4.3. Assign development staff 4.4. Develop code 4.5. Developer testing (primary debugging) 4.6. Development complete 5. Testing 5.1. Develop unit test plans using product specifications 5.2. Develop integration test plans using product specifications 5.3. Unit Testing 5.3.1. Review modular code 5.3.2. Test component modules to product specifications 5.3.3. Identify anomalies to product specifications

5.3.4. Modify code 5.3.5. Re-test modified code 5.3.6. Unit testing complete 5.4. Integration Testing 5.4.1. Test module integration 5.4.2. Identify anomalies to specifications 5.4.3. Modify code 5.4.4. Re-test modified code 5.4.5. Integration testing complete 6. Training 6.1. Develop training specifications for end users 6.2. Develop training specifications for helpdesk support staff 6.3. "Identify training delivery methodology (computer based training, classroom, etc.)" 6.4. Develop training materials 6.5. Conduct training usability study 6.6. Finalize training materials 6.7. Develop training delivery mechanism 6.8. Training materials complete 7. Documentation 7.1. Develop Help specification 7.2. Develop Help system 7.3. Review Help documentation 7.4. Incorporate Help documentation feedback 7.5. Develop user manuals specifications 7.6. Develop user manuals 7.7. Review all user documentation 7.8. Incorporate user documentation feedback 7.9. Documentation complete 8. Pilot 8.1. Identify test group 8.2. Develop software delivery mechanism 8.3. Install/deploy software 8.4. Obtain user feedback 8.5. Evaluate testing information 8.6. Pilot complete 9. Deployment 9.1. Determine final deployment strategy 9.2. Develop deployment methodology 9.3. Secure deployment resources 9.4. Train support staff 9.5. Deploy software 9.6. Deployment complete

10. Post Implementation Review 10.1. Document lessons learned 10.2. Distribute to team members 10.3. Create software maintenance team 10.4. Post implementation review complete 10.5. Software development template complete

2. Listing of risks involved in this project 20% 1.Inherent schedule flaws Software development, given the intangible nature and uniqueness of software, is inherently difficult to estimate and schedule. Wrong time estimation Resources are not tracked properly. All resources like staff, systems, skills of individuals etc. Failure to identify complex functionalities and time required to develop those functionalities. Unexpected project scope expansions. 2.Requirements Inflation As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten estimates and timelines. 3.Employee Turnover Key personnel leave the project taking critical information with them that significantly delays or derails the project. 4.Specification Breakdown When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements. 5.Poor Productivity Given long project timelines, the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained. 6.Budget Risk Wrong budget estimation. Cost overruns Project scope expansion 7.Operational Risks: Risks of loss due to improper process implementation, failed system or some external events risks.

Causes of Operational risks: Failure to address priority conflicts Failure to resolve the responsibilities Insufficient resources No proper subject training No resource planning No communication in team. 8.Technical risks: Technical risks generally leads to failure of functionality and performance. Causes of technical risks are: Continuous changing requirements No advanced technology available or the existing technology is in initial stages. Product is complex to implement. Difficult project modules integration. 9.Programmatic Risks: These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program. These external events can be: Running out of fund. Market development Changing customer product strategy and priority Government rule changes.

3. Drawing of grant chart 20% Please see Ms. Project file Name: Software Development.mpp 4. Planning suitable requirement gathering techniques 20% 1. Brainstorming Brainstorming helps in requirements elicitation to get as many ideas as possible from a group of people. In this project, it helps to identify possible solutions to Machine Integration problem, and clarify details of opportunities. Brainstorming casts a wide net,

identifying many different possibilities. Prioritization of those possibilities is important to finding the needles in the haystack. 2.Document Analysis Reviewing the documentation of an existing Manual system can help when creating Process documents and Designing the system. would even be reviewing the requirements that drove creation of the existing system a starting point for documenting current requirements. Nuggets of information are often buried in existing documents that help us ask questions as part of validating requirement completeness. 3.Focus Group A focus group is a gathering of people who are representative of the users or customers of a product to get feedback. The feedback can be gathered about needs / opportunities / problems to identify requirements, or can be gathered to validate and refine already elicited requirements. 4. Interview Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly weigh and address their inputs. 5. Observation The study of users in their natural habitats is what observation is about. By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process. Either approach can be used to uncover implicit requirements that otherwise might go overlooked. 6. Prototyping Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people can not articulate a particular need in the abstract, they can quickly assess if a design approach would

address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. 7. Survey When collecting information from many people too many to interview with budget and time constraints a survey or questionnaire can be used. The survey can force users to select from choices, rate something (Agree Strongly, Agree), or have open ended questions allowing free-form responses. Survey design is hard questions can bias the respondents.

Thank you,