Loading ...
Global Do...
News & Politics
2
0
Try Now
Log In
Pricing
Given below is a Project Management Plan for a real life project executed by a commercial company. This example is from my book Software Project Management in Practice (2002, Addison Wesley).The project planning here follows the methods and style of the parent company, some of which have been discussed in the Chapter. The plan here does not give the CM plan or the detailed schedule of project tasks – more on these are available in the book. How the plan was evolved and the methods followed for it are also given in the book. PROJECT MANAGEMENT PLAN FOR ACIC PROJECT 1. PROJECT SUMMARY 1.1 Project Overview ACIC is a USA-based Investment firm. This application has 2 components. First, a Brokerage Account Opening application on ACIC’s web-site which will allow any Internet user to open a Brokerage Account with ACIC. Second, an account opening and maintenance application which is primarily for ACIC’s representatives to open accounts for the applications received in Paper format. This is an Intranet application. The application will provide features like account history viewing and account balance, status and activity information. This will allow ACIC to effectively evolve to a client/account servicing application in addition to being an account opening engine. This is an enhancement of an existing application; the earlier development was also done by Infosys. Project code Project Name Customer xxxxxxxxx ACIC Project ACIC Corporation Project Leader(PL) Configuration Controller( CC) Business Manager(BM) Backup PL Backup CC BB SB HR BS HP Project Type Platform Number of Phases Development Java, Win NT, DB2 Four Phases. Project Start Date (including onsite, offshore) On-site Off-shore Project end date Total Estimated Revenue April 3rd, 2000 May 15th, 2000 Nov 3rd, 2000 US $ xxx,xxx Project and Customer Contact Personnel Name and Designation Phone number Fax number E-mail id. Project Scope To provide an effective, efficient means of account maintenance activities To allow reps to access information. Provide a complete picture to the client rep for account status, valuation, order status, and trade activity Increase the intelligence of the update process Provide an interface that is able to display required account history elements Provide capability to close and reactivate an account Project's Value-add to the customer This project will allow ACIC to effectively evolve to a client account servicing application in addition to being the account opening engine. Infosys Objectives Strengthen relationship with ACIC by delivering high quality software on time. Become preferred vendor by developing expertise on their products and systems. 1.2 Commitments made to the customer Sl# Milestone Date Milestones Deliverables 1 26th May 2000 Inception: Requirements Signoff Business analysis and requirements specifications, Use-Case catalog, Screens, Iteration plan 2 15th May – 23rd June 2000 Elaboration: Iteration-1 Sequence diagrams, Class diagram, Source code, Plan for the next cycle 3 26th June – 7th July 2000 Elaboration: Iteration-2 Supplementary specifications, Sequence diagrams, Class diagram, Architecture document, Source code, Iteration plan for the next cycle 4 10th July – 21st July 2000 Construction: Iteration-1 Source Code, Review reports, Test reports, Iteration plan for the next cycle 5 20th July – 28th July 2000 Construction: Iteration-2 Source code, Review reports, Test reports, Iteration plan for the next cycle 6 31st July – 8th Aug 2000 Construction: Iteration-3 Source Code, Review reports, Test reports, Iteration plan for the next cycle, Deployment plan for the product 7 9th Aug – 1st Sep 2000 Integration Testing Phase Test Plans, Test reports 8 4th Sep – 15th Sep 2000 Onsite Code delivery and setup Code 9. 18th Sep – 22nd Sep 2000 Acceptance Test and Production migration Test reports 10. 18th Sep – 29th Sep Onsite Reconciliation Code 2000 and Regression Test 11. 2th Oct– 26th Oct 2000 Acceptance Test Test Results 12. 27th Oct – 3rd Nov 2000 Roll out and Support Project Sign off Other commitments Sl# Commitments 1 This project will follow the Rational Unified Methodology (RUP). 1.3 Assumptions Assumptions made while planning • Migration to Visual Age for Java 3.0 will not be done by this team • Intelligent update to business partners will be incorporated in only the maintenance part of the application and not in the ‘Account opening’ engine • Qualified people will approve ‘Rational Unified Process’ methodology for implementing this project • Changes in functional and technical requirements during the life cycle of the project may have an impact on the schedule. Any impact on cost or schedule due to these changes will be intimated to ACIC • ACIC reviewers will get 7 days to approve a milestone document. If no comments are received within this time period, it will be considered as approved. 2. PROJECT PLANNING 2.1 Project Processes Standard Process followed The standard development process of Infosys will be followed. However, it will be enhanced with Rational Unified Process methodology (RUP), as it is a commitment. The development process will be tailored to match the RUP. Tailoring Notes Deviations from standard process Added/Modified/Deleted Reasons for deviations Only those use cases that are going to be taken up in a particular iteration will be elaborated at that point of time. Modified As iteration based development is being done Development of logical object Modified Conformance to RUP model will be done incrementally in the first few iterations methodology Development of physical object model will be done incrementally in the first few iterations Modified Conformance to RUP methodology Physical database design may be refined in later iterations Modified Conformance to RUP methodology Development of unit test plan will be done in each iteration Modified As iterative approach is being used Logging of defects will be iteration wise Modified As iterative approach is being used Requirement traceability will be done through the Requisite Pro tool Modified Conformance to RUP methodology No vision document and Business case, as we started with the ‘Scope document’ which serves the same purpose Modified Deviation from RUP Requirements Change Management Process Change Requests Tracking • Changes requested by customer will be logged in ChangeRequest.xls and analyzed for impact on the project. A change request form will be submitted to customer for approval. Change requests that are approved will be attached to the project contract as addenda. • Major changes usually have an effort / delivery-on-time impact on the project. The customer needs to formally approve these. • As this is a short duration project, if any one or a group of change requests takes more than 2% of the total estimated effort for the project, re-estimation of the project schedule and effort will be done. Requirements Traceability Requisite Pro tool will be used. 2.2 Estimated Size and Effort Estimation Criteria Program/Function ( Use Case ) Criteria Simple Use Case 3 or Fewer Transactions Medium Use Case 4 to 7 Transactions Complex Use Case > 7 Transactions Use Case Description Complexity Number Use Case 1 Screen Navigation Complex Use Case 2 Update Personal Details Medium Use Case 3 Add Address Medium Use Case 4 Update Address Complex Use Case 5 Delete Address Complex Use Case 6 Add Telephone Number Medium Use Case 7 Update Telephone Number Complex Use Case 8 Delete Telephone Number Complex Use Case 9 Add Email Medium Use Case 10 Update Email Medium Use Case 11 Delete Email Medium Use Case 12 Update Employment Details of a party Medium Use Case 13 Update Financial Details of a party Medium Use Case 14 Update Details of an Account Medium Use Case 15 Maintain activities of an Account Complex Use Case 16 Maintain memos of an Account Simple Use Case 17 View History of Party Details Complex Use Case 18 View History of Account Details Complex Use Case 19 View History of Option Level and Service Options Simple Use Case 20 View History of Activities and Memos Simple Use Case 21 View History of Roles Complex Use Case 22 View Account Details Simple Use Case 23 View Holdings of an Account Complex Use Case 24 View ‘Pending Orders’ of an Account Complex Use Case 25 Close/Reactivate Account Simple Use Case 26 Intelligent update to business partner of ACIC Complex Estimated Build Effort Program/Function Effort (Based on data from earlier project) Number of Units Total Build Effort (in person-days) Simple Use Cases 1 Person Days 5 5 Medium Use Cases 5 Person Days 9 45 Complex Use Cases 8 Person Days 12 96 TOTAL 146 Phase-wise Effort Estimate Activity/Phase Person-days % of total effort Requirements 50 10 Design 60 12 Build 146 29 Integration test 35 7 Regression Test 10 2 Acceptance test 30 6 Project management 75 15 Configuration management 16 3 Training 50 10 Others 40 6 Estimated Effort 501 100% Effort Estimate by Iterations Person days % of Total Effort Project Initiation 25 5 Inception Phase 24 5 Elaboration Phase: Iteration-1 45 9 Elaboration Phase: Iteration-2 34 7 Construction Phase: Iteration-1 27 5 Construction Phase: Iteration-2 24 5 Construction Phase: Iteration-3 21 4 Transition Phase 110 22 Project Closure 10 2 Project Management 75 15 Configuration Management 16 3 Training 50 10 Others 40 8 Total Estimated Effort 501 Person Days 100% 2.3 Schedule Specified as milestones in the section on Commitments to the Customer. 2.4 People People by Role Role Required# Date PL 1 4th May 2000 Onsite Co-ordinator 1 ( 50% time ) 4th May 2000 Module Leader 1 15th May 2000 Developers 3 15th May 2000 Developers 1 17th July 2000 Developers 1 1st August 2000 Developers 1 14th August 2000 Total 9 (actually 8.5) People by Skill and Experience Area Total # 0-12 months experience > 12 months experience Java 7 7 0 DB2 2 0 2 Total 9 7 2 People Requirement Plan Month Offshore Onsite Total May 2000 4 1 (50%) 5 June 2000 5 1 6 July 2000 5 1 6 Aug 2000 8 1 9 Sep 2000 7 2 9 Oct 2000 3 2 5 2.5 Development Environment Hardware Software • NT Server • WIN NT • MainFrame • DB2 • Intel PC • Visual Age for Java, Java, Win NT 2.6 Hardware and Software Resources Required Item Description Required # Date PCs with 128 RAM 6 1st May 2000 1 GB space on server 1 1st May 2000 Visual Age for Java 6 4th May 2000 DB2 6 4th May 2000 Rational Rose 5 15th May 2000 Requisite Pro 1 15th May 2000 2.7 Tools Tools List Tools to be developed in the project None In-house tools to be used in the project None 2.8 Training Plan Training Area Duration Waiver Criteria Technical Java Language 7 days • If already trained Visual Age for Java 3days • Exposed as part of initial training Java Applets 4 hrs • If already trained Java Swing 4 hrs • If already trained Persistence Builder 4 hrs • If already trained Rational Rose and Requisite Pro 8 hrs • Mandatory OOAD 1day • If already trained Business domain System Appreciation 7 days • If already trained Process Related Quality system 3 hrs • If already trained Configuration Management 2 hrs • If already trained for CC. For others on the job training Group Review 4 hrs • If already trained Defect prevention 4.5 hrs • Mandatory SPC tool 4.5 hrs • If already trained RUP methodology 2 hrs • Mandatory 2.9 Quality Plan Quality Goals Project Quality Goals Goals Value Basis for setting goals Org.wide Norms Total number of defects injected 145 0.033 defects/Person hour. This is 10% better than Synergy 1.5, which is 0.036 defects/Person Hour 0.052 defects/Person Hour. Quality (Acceptance defect density) 5 3 % or less of total estimated number of defects 6% of estimated number of defects Productivity 57 3.4 % productivity improvement to Synergy 1.5 50 Schedule Delivery on time 10% Cost of quality (In %) 32% 31.5% 32% Estimates of defects to be detected Review / Testing stage Estimated number of defects to be detected % of defects to be detected Basis for estimation Requirements & Design review 29 20% Referenced similar Project estimations (Synergy 1.5) and PCB Code review 29 20% -Do- Unit testing 57 40% -Do- Integration + Regression testing 25 17% –Do- Acceptance Test 5 3% -Do- Total estimated number of defects to be detected 143 100% Strategy for meeting Quality Goals Strategy Expected benefits Do defect prevention using the standard defect prevention guidelines and process; use standards developed in synergy for coding. 10 -20 % reduction in defect injection rate and about 2% improvement in productivity Group Review of Program specs for first few/logically complex Use Cases Improvement in quality as overall defect removal efficiency will improve; some benefits in Group review of design docs/first time- generated code by Project Leader, Developer and one Consultant. productivity as defects will be detected early. Introduction of RUP methodology and implementing the project in iterations. Milestone analysis and defect prevention exercise will be done after each Iteration. Approximately 5 % reduction in defect injection rate and 1% improvement in overall productivity Reviews Review Point Review Item Type of review End of Project Planning Project Plan DCS set up Project Schedule Group Review SQA Review SQA Review End of Project Planning CM Plan Group Review End of 90% of Requirements ( This should be at the end of First Elaboration Iteration ) Business analysis and requirements specification document, Use Case Catalog Group Review End of 90% Design ( This should be at the end of Second Elaboration Iteration ) Design Document, Object Model Group Review Beginning of each Iteration Iteration Plans One person review End of Detailed design Complex/first time generated Program Specs incl. Test Cases, Interactive diagrams Group Review After coding for first few programs Code Group Review After self testing of a process Code One person review End of Unit Test Plan Unit Test Plan One person review Beginning of Integration Test Integration Test Plan Group Review 2.10 Risk Management Plan Sl # Risks Proba bility Imp act Risk Expo sure Mitigation Plan 1 Support from database architect and the database administrator of the customer 0.5 8 4 • Plan carefully for the time required from each of this groups and give enough prior notice • Onsite co-ordinator to work closely with these groups 2 As RUP is being used for the first time, the understanding of the team may not be complete 0.9 3 2.7 • Work closely with experts in the R&D lab of Infosys • Keep the customer in the loop throughout the project and escalate for any Schedule/Effort deviations • Train the team on RUP methodology 3 Personnel Attrition: Team members might leave at short notice. 0.3 7 2.1 • Assign tasks so that more than one person is aware of the units/use cases in the project 4 Working with customer’s mainframe DB2 over the link – link may not be as efficient as it is expected. 0.1 8 0.8 • Do extra code reviews, desk checking etc. to minimize the reliance on link • Escalate as soon as the link goes down. 3. PROJECT TRACKING 3.1 Measurement Plan Metric to be collected Unit of Measurement Tools used Size LOC , FP, S/M/C count • Line counters Effort Person-days • WAR Defects Number of Defects • BugsBunny Schedule Elapsed time • MSP 3.2 Task Tracking Activity Procedure Task scheduling • The PL schedules tasks using MS Project • Refinement and rescheduling will be done when necessary Task assignment • The latest schedule is made available to the team members. Once the Schedule is uploaded to WAR-MSP system, the tasks will show in their respective WARs. Task status tracking • Task tracking is done daily. Project meeting • Once a week. Causal analysis meeting • After every iteration 3.3 Issues Tracking Issues Types Where logged Who can log Who reviews, when When Escalated Onsite Issues IssueTracker.xl s Any member of the project PL, Daily 2 days Customer Issues Issues Log.xls Onsite team, PL PL, Daily 2 days Business Manager Issues Weekly Status report BM BM, PL Weekly 5 days Issues with Support Services Request Tracker Any team member Support Services, Daily 2 days 3.4 Customer Feedback Item Logging and Tracking Process Customer Feedback • The AM/PL gets the customer feedback. The BM files it. Customer Complaints • Customer complaints received will be entered and tracked using CustomerComplaints.xls 3.5 Quality Tracking Quality Activity Action Defect tracking Use DCS for logging defects and tracking them to closure Reviews (requirements, high level design, detailed design) Check against project goals in quality plan Code review Check against limits for each program through SPC tool Independent unit testing Check against limits for each program through SPC tool Integration testing/System testing Check against project goals in quality plan 3.6 Review by Senior Management (BM) Sl# Item for review Frequency of review 1. Schedule Every version change 2. Project plan When some significant changes are made 3. Milestone report End of milestones 3.7 Status Reporting Report To Frequency Business Manager Weekly on Monday by e-mail Customer Weekly on Monday 3.8 Deviation Limits at Milestones Actual vs estimated of: For the first five milestones For the rest of the milestones Effort 10% 5% Schedule 10% 5% Defects 20% 20% 3.9 Report to the Customer • Milestones reports and weekly status reports • Issues requiring clarifications • Escalation, if any 3.10 Report to the BM • Customer feedback • Milestones and weekly status reports • Issues requiring clarifications/attention • Escalation, if any • Number of Requirement changes and estimated effort for them • Major changes in Plan 3.11 Escalation Procedures Escalate Where Threshold period Name of the person Designation of the person At ACIC 3 days Xxxx Project Manager At Infosys 3 days Xxxx Account Manager At Infosys 3 days Xxxx Business Manager 4. PROJECT TEAM 4.1 Project Organization Customer AM BM (Offshore) PM SQA DP Team ML CC DV 4.2 Project Team . Sl. # Initials Responsibility Start date Expected End Date 1 BB Project manager 4th April 2000 3rd November 2000 2 KP Onsite Co-ordinator 4th April 2000 3rd November 2000 3 BS Module leader, backup project lead 15th May 2000 3rd November 2000 4 SP Configuration controller 22nd May 2000 13th October 2000 5 DD Developer 22nd May 2000 29th September 2000 6 HP Developer, backup configuration controller 22nd May 2000 29th September 2000 7 NA Developer 17th July 2000 3rd November 2000 8 SH Developer 1st August 2000 15th September 2000 9 AL Developer 14th August 2000 31st August 2000 10 JP Developer 1st September 2000 22nd September 2000 11 SDS Account manager 4th April 2000 3rd November 2000 12 SB SQA 15th May 2000 3rd November 2000 4.3 Roles and Responsibilities Role Responsibilities Business Manager (BM) Resolve escalated issues Review project status Participate in critical technical reviews Customer Review design Resolve escalated issues Acceptance test planning & testing Account Manager (AM) Customer satisfaction Business growth Project financial plan Interfacing with sales and marketing Training related issues Employee related issues Project manager (PM) Project planning & scheduling Design Customer interaction Reviews Testing Reporting Task assignment & tracking Interact with software quality advisor from SEPG Ensure delivery as per contract Interface with other departments as per need Ensure open issues/customer complaints are closed properly Ensure project members are adequately trained Module leader (ML) Design Development Testing Reporting Defect prevention team (DP Team) Spread awareness in the team on defects and their prevention Analyze defect data Identify methods to reduce defect injection Developer (DV) Detail design for use cases Development Unit Testing & integration testing Configuration controller (CC) Prepare the CM plan Manage the configuration as per the CM plan Software quality advisor (SQA) – from the SEPG Process consultancy Quality assurance (audits) Install measurement tools & train project personnel Participate in reviews of project Plan & processes as necessary Onsite Co-ordinator Resolve any issues from Customer/Offshore Support during development 5. REFERENCES Omitted. 6. ABBREVIATIONS USED Ommitted.
