Consulting KPMG Gap Analysis Report - FSoft

1、KPMG ConsultingPage 9 REPORT OF GAP ANALYSIS IN FSoftDocument IDKPMG/CMM/BLR/FSoft 1Version1.0NameSignatureDatePrepared M.S Sivakumar5 May 2001 8 May 2001Reviewed & ApprovedKK Raman KPMG Consulting India Pvt. Ltd 1. Purpose and Scope of the Consulting Assignment: The consulting assignment was fo

2、r Gap Analysis of FSoft to Level-4.2. Team Involved: · The KPMG team consisting of M.S Sivakumar was involved in the assignment. · The organization team was represented by the following people :Gap Analysis TeamProject/FunctionLe The HungSEPG HeadPhan Van HungManagerNguyen Thu HaMemberThe

3、people along with designations and the projects involved from FSoft are as listed below:TeamProject/FunctionNguyen Quang HoaHarvey NashNguyen Dac Viet Dung, Hoang Thanh Son WinsoftDang Dieu LinhSBOITran Thuc Quyen, Le Thi Hang, Dang Dieu Linh, Nguyen Thu Ha, Dao Hong Le, Dang Thuy HanhSQALe The Hung

4、, Phan Van Hung, Nguyen Thu HaSEPGLe Thi Hang, Phan Van Hung, Nguyen Thu Ha, Tran Thuc QuyenSCMPhan Phuong Dat, Khuat Thanh Thuy, Lai Thai NguyenHR & TrainingNguyen Hoang Viet, Trinh Thu Hong, Nguyen Duc QuynhSystem AdministrationThe documents like Project Management Process, SCM Process, tailor

5、ing guidelines etc were reviewed 3. Findings of the Gap AnalysisLevel-2 Key Process Areas1. Requirements Management· There were no records of analysis of requirements in some of the projects· Analysis was done in some of the projects but the same was not documented in the Analysis template

6、 (tailoring guidelines in the case were its a continuation of a project)· There was no SRS in some of the projects; Business Requirements Document was used; tailoring guidelines could be updated to allow this· Review of requirements were not properly documented in some of the projects·

7、; Training on requirements management was not adequate · Some projects use Rational unified process, but there was no training on RUP· Some projects did not have metrics on RM· The change in requirements from the customer were documented and analysis for impacted items were done, but

8、the same was not documented, impact analysis forms are available in the organization· The requirements from customer were kept as mails, but the same was not easily traceable· The organization could come up with tailoring guidelines for requirements management activities for small projects

9、· Metrics on RM need to be consolidated at project closure· Some of the projects did not have SQA review in RM· There were no records of senior management review in some of the projects2. Software Project Planning · Tailoring could be done in the case of project plans with shorte

10、r durations, tailoring guidelines to address the same· Critical paths and dependencies to be identified in projects· Training on the planning process with filling of sample forms in the class to demonstrate the usage of templates needs to be done· The organization could organize a tra

11、ining on MS project by one of the internal members· Some of the projects did not have planning for the planning stage and the efforts for the same· Metrics for SPP could be consolidated at the end of the project· Records were not maintained for SQA review in some of the projects·

12、 SQA review of planning activities in some of the projects was not done3. Software Project Tracking and Oversight· The projects have the practice of project diaries, its recommended to move to structured minutes of meeting, with the open action items getting moved to the next meetings agenda to

13、 facilitate tracking · Mpp files are made, but tracking is mainly through tracking sheet, tailoring guidelines could be made whereby projects of very short duration could do away with MS Project.· Time sheets in some of the projects were not approved even after project closure· Data w

14、as not found related to planned and actual in some of the projects· Risks are identified in the project plan and tracked in the plan itself, its suggested that risk tracking could be through a separate sheet, by which we need not change the plan more often and this sheet could be referred in th

15、e project plan· Size tracking has to be in place (Need to move to FP)· It was found that the team members need to be trained/made more aware about entering data in timesheets · Re-estimation data was not available in projects· Effort for project tracking to be captured and metric

16、s could be consolidated at the end of the project· SQA needs to verify minutes of meeting and schedules and plans and find out whether the project is as per plans and whether the tracking issues are getting closed and if not escalated to the senior management4. Software Quality Assurance·

17、A checklist for SQA could help the SQAs in reviewing the projects in each stage like RM, PP, PTO etc· The efficiency of reviews by SQA needs to be increased more and cover more aspects like checking whether review action items are closed in the report· SQA review records from audits and re

18、views to be made and this need to be maintained in project folders also· Effort needs to be segregated for different activities · Training slides for SQA to be updated using CMM information, the kind of checks the SQA has to do for different phases and work products· Audits were not s

19、cheduled in the project· Audits on SQA has to be done by some senior project members in FSoft5. Software Subcontractor Management · Not covered6. Software configuration Management· Its advisable to use VSS for all CIs including documents· Procedure for baselining and audits to be

20、 defined in the SCM Process· The template now in PP for SCM is confusing and may be changed · Adequate training has to be given in process as well as tools for SCM· Configuration status reports were generated but there was no verification by the PL and the same was not used for commun

21、icating to the team· Baseline Audits are not done · Configuration audits have to be scheduled· Items which are cause of concern, related to configuration management could be discussed in the project progress meetings to bring to the light of senior management· SQA verification wa

22、s done but records were available/not available in projectsLevel-3 Key Process Areas1. Organization Process Focus· SEPG has to document all its operations like Metrics Analysis and entering them into process database, Postmortem Analysis and discussion forums, PCB analysis, Best Practice Analys

23、is etc · The SEPG has to periodically look at the OSSP, thro methods like internal quality audits etc, (through tools like Pareto Diagrams, Root Cause Analysis etc) analyze the areas for improvement by looking at the NCs and come out with action plans for improving the select areas· The pr

24、ocess database has to be maintained by SEPG in association with QA group, the data thats coming to the database has to be evaluated by the SEPG before inputting into the database· The process deviations coming from projects have to be analyzed by the SEPG, a standard procedure to be followed fo

25、r this· Periodicity of SEPG meeting to be determined and mentioned in the charter· The process database is coming up, it should have more details like good risk management techniques used by projects, assumptions used in estimation by the project, list of deviations etc· Effort captur

26、e under CMM and SQA titles is happening, Timesheets to be in place for capturing SEPG activities with detailed activity codes like PCB preparation, Process Definition etc· SEPG to be audited by members from some senior project members 2. Organization Process Definition· Tailoring guideline

27、s should be developed for catering to different sections/processes of the organization· Process assets from closed projects need to go into a process assets library, this library will have assets like Project Plans, SRS, URD, Metrics Sheet, Post Mortem Reports, Estimation Sheets, Test Plans and

28、 Procedures, Test Cases, Design Documents etc.3. Training Program· Training needs are identified at the start of the project informally, this needs to be part of the project plan and then tracked to closure· HR forecast is currently done for the organization, this could give inputs for tra

29、ining needs in the organization also· Training group has to review to the project plans so as to identify the training requirement and plan for the same· Format for feedback from the attendee to have more fields for feedback on the instructor and the quality of the course· Course mate

30、rial review to be in place in the process as well as in practice· Analysis of metrics on training like attendance data, course quality data as well as instructor rating to be in place· Standard templates for courseware to be in place with slides like objective, subject, reference test/quiz

31、 etc· The training group could give orientation to the project groups· Waiver approval should be done by the associated manager· Training group to be audited once in 6 months and the audit to be done 4. Integrated Software Management· Training in Tailoring aspects to be given to

32、the project teams, this could be even part of the project planning training · The organization process database should be used for estimation· PMs/PLs should be trained in the use of MS Project and management of critical dependencies and critical paths· Handling of Critical Dependenci

33、es and Critical Paths should be according to a documented procedure· Currently there is a PL training in the organization, the training could be improved with team building and other leadership techniques· Revisions to DSP (the tailored project plan) should be according to a documented pro

34、cedure· Customer specific or domain specific training could be prepared so that new members could be easily trained on the same and knowledge capturing and sharing happens easily5. Software Product Engineering· Requirements traceability matrix needs to be established in projects· The

35、effort capture for the different phases needs to be segregated and the metrics needs to be consolidated at the end of each phase· It was found that the defect data for reviews and testing was clubbed together, the same needs to be separated to calculate the efficiency of the processes· Tes

36、t plans and test cases are made by test leader, and reviewed by the project leader, but records are not available in some projects· The severity and origin columns in the peer review report were not filled in some projects· The organization could take up initiatives for domain training lik

37、e POS/Mobile Computing etc6. Intergroup Co-ordination· Service Level Agreements/Response Time Indicators to be set by the support groups like Network Administration/Purchase etc and should be made aware to the projects through intranet page/communications· Projects could have kick off meet

38、ings were support groups could participate· Network Administration group could have metrics based on the type of calls they receive· Network Administration group to plot charts on the data collected and analyze the data 7. Peer Reviews· The items to be peer reviewed and the responsibi

39、lity should be defined in the project plan; the tasklist could identify the peer review members· The peer reviews have to be scheduled· Focused training on Peer Reviews and Review Team Leaders (may be project leaders and training part of PL training) to be trained · PR report has to i

40、dentify the person who has done the review and the effort taken for doing the peer review and size of the work product (LOC in case of software and Pages in case of documents)· The peer review defects should be analyzed with respect to the type and severity ( Pls refer to ODC) · Metrics to

41、 be in place like no of peer reviews planned Vs actual, effort for peer reviews and defect data· SQA reviews to look into aspects of peer reviewLevel-4 Key Process Areas1. Quantitative Process Management · Quantitative Process Management process to be modified with identification of new me

42、trics· SEPG plan should mention the release of process capability baselines· Plotting Tools to be in place for aiding projects· Training on QPM to projects, the training should focus on areas like setting up goals based on PCB, tailoring of quantitative goals, metrics collection, anal

43、ysis of metrics using tools like control charts, pareto charts, Ishikawa Diagram and other tools· Planned activity for achieving the goals to be mentioned in the PP· The projects should analyze the data periodically, currently its sent that analysis (using tools like control charts, Ishika

44、wa Diagram, Pareto Diagrams etc) will be done only at the end of projects, for longer duration projects (>1 month), it should be done periodically where as short duration projects could have tailored means of analysis· Procedure for Process capability Baselines should be formed and it could be part of Metrics process· Change in PP template to accommodate QPM areas like organization norm, rationale for arriving at the goal if the goal is a tailored one from the organization goal, the strategy planned for achieving the goal etc· Tailoring Guidelines