1 / 117

Knowledge in implementing/managing the IS/IT project – technically

Knowledge in implementing/managing the IS/IT project – technically. Group 3. Teacher: Dr. Celeste Ng. GAPPS- Project Manager Standards. 961660 蔡嘉妍. GAPPS. G lobal A lliance for P roject P erformance S tandards is called GAPPS.

swhitaker
Download Presentation

Knowledge in implementing/managing the IS/IT project – technically

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Knowledge in implementing/managing the IS/IT project – technically Group 3 Teacher: Dr. Celeste Ng

  2. GAPPS-Project Manager Standards 961660 蔡嘉妍

  3. GAPPS • Global Alliance for Project Performance Standards is called GAPPS. • It has two Standards─Project Manager Standards and Program Manager Standards.

  4. The CIFTER • The GAPPS framework uses a tool called the Crawford-Ishikura Factor Table for Evaluating Roles, or CIFTER.

  5. The CIFTER(con.) • The CIFTER factors identify the causes of project management complexity. • For example, in some application areas, a project manager's ability to control project costs is considered to be the primary factor in determining competence.

  6. The CIFTER(con.) • The CIFTER identifies seven factors that affect the management complexity of a project.

  7. The factors of the CIFTER 1. Stability of the overall project context • The project context includes the project life-cycle, the stakeholders, the degree to which the applicable methods and approaches are known, and the wider socioeconomic environment.

  8. The factors of the CIFTER (con.) 2. Number of distinct disciplines, methods, or approaches involved in performing the project. • Most projects involve more than one management or technical discipline; some projects involve a large number of different disciplines.

  9. The factors of the CIFTER (con.) • For example, a project to develop a new drug could include medical researchers, marketing staff, manufacturing experts, lawyers, and others. • Since each discipline tends to approach its part of the project in a different way, more disciplines means a project that is relatively more difficult to manage.

  10. The factors of the CIFTER (con.) 3. Magnitude of legal, social, or environmental implications from performing the project. • This factor addresses the potential external impact of the project.

  11. The factors of the CIFTER (con.) • For example, the potential for catastrophic failure means that the implications of constructing a nuclear power plant close to a major urban centre will likely be much greater than those of constructing an identical plant in a remote area.

  12. The factors of the CIFTER (con.) 4. Overall expected financial impact (positive or negative) on the project's stakeholders. • This factor accounts for one aspect of the traditional measure of “size,” but does so in relative terms.

  13. The factors of the CIFTER (con.) • For example, a project manager in a consumer electronics start-up is subject to more scrutiny than a project manager doing a similarly sized project for a computer manufacturer with operations around the globe.

  14. The factors of the CIFTER (con.) 5. Strategic importance of the project to the organization or organizations involved. • This factor addresses yet another aspect of “size,” and again deals with it in relative rather than absolute terms.

  15. The factors of the CIFTER (con.) 6. Stakeholder cohesion regarding the characteristics of the product of the project. • When all or most stakeholders are in agreement about the characteristics of the product of the project, they tend to be in agreement about the expected outcomes as well.

  16. The factors of the CIFTER (con.) 7. Number and variety of interfaces between project and other organizational entities. • In the same way that a large number of different disciplines on a project can create a management challenge, a large number of different organizations can as well.

  17. The CIFTER • Each factor is rated from 1 to 4 using a qualitative point scale, and the factors are totalled to produce a management complexity rating for the project.

  18. The CIFTER • It can provide some guidance to help you make better decisions when you do have options. • In addition, you can use it to assess your current assignments. • While you probably won’t be able to create perfect alignment, highlighting major mismatches will at least tell you which projects you should be paying special attention to.

  19. Source • GAPPS─http://www.globalpmstandards.org/index.php/project-manager-standards.html • http://www.asapm.org/asapmag/articles/cifter.pdf

  20. CPPMGuideA Guide to the Project &Program Management Standard Certified Project Manager (CPM) and (CPP)Essential Tips and Guidebook for Undertaking the CPM & CPP certificationTHE INTERNATIONAL ASSOCIATION OF PROJECT AND PROGRAM MANAGEMENT (IAPPM) 961703 何沛錦

  21. Project Discovery Best Practices • Defining the project To draft the initial version of the project charter – the project definition document. • Requirements gathering and scoping Once the initial project definition has been accepted by all relevant parties, the next step is to scope the project in detail. • Considerations • Business processes that will be affected; • Business areas/units that will be affected; • Business locations that will be affected; • Business data that will be changed; • Business applications that will be changed; • Technologies that will be changed

  22. Project Discovery Best Practices • Meeting the business needs The successful PM (Project Manager) is one that understands the true business need and shapes the project to support this need.

  23. Project Planning Best Practices (I) • Elements of project planning • Resource requirement planning • Project budgeting • Project schedule • Project communication • Vendor selection • Training preparation • Business process documentation • Contingency and risk management • Security and privacy planning • Business continuity planning • Post-project planning

  24. Project Planning Best Practices (II) • Project Decision Making IAPPM recommends the following approach for consistent decision making: • Defining the problem or problems • Verification of the problem parameters • Prioritization of problems • Elimination of emotional factors • Evaluating options • Group decision making

  25. Project Deployment and Project Control Best Practices (I) • Status reporting and project review Status reporting is a mechanism to add value to the review of the specific project. Status reports can be generated using either the following ways: • Online status reports generated automatically from a scheduling tool, such as Niku, MS Project, etc • Manual based status reports using tools such as MS PowerPoint or MS Word. • Email

  26. Project Deployment and Project Control Best Practices (II) The PM need only ensure that this report is done on a timely basis and should incorporate some of the following items: • Milestones achieved for that week or month • Upcoming milestones or deliverables • Issues and Risks that have arisen • An indication of project status through color coding the entire project or work stream • Key concerns • Dependencies that have not been identified or addressed • Outstanding decisions

  27. Project Deployment and Project Control Best Practices (III) • Quality management and customer satisfaction The ultimate goal of any project is to satisfy the customer or requestor. • Practical Approach to QA/QC (Quality Assurance/Quality Control) • Communicate your commitment to the QA team and drive quality in everything • Never run a project status meeting without a QA person being present • If you determine no QA resources are available for your project or program, ensure there is funding to buy the necessary resources • Do not delay bringing in QA resources to the team

  28. Project Deployment and Project Control Best Practices (IV) • Practical Approach to QA/QC (cont.) • On a global project with different regions (ie, EMEA, ASPAC, LATAM, NA) ensure you have a QA resource allocated to each region • Sometimes North America project or program team leads fails to see the value ofthe way things are done in other regions and in other countries. • Do not under-estimate time to develop test scripts or test plans or user testing. Usually this takes longer than expected.

  29. Project Deployment and Project Control Best Practices (V) • When to terminate a project or program Factors that lead to a project being cancelled are as follows: • Any major, impact or change in the project scope • The introduction of a severe risk which impacts the entire organization • A specific assumption is found not to hold true anymore • Product fails to achieve goal • Supplier cannot meet commitments • When the business strategy does not necessitate the need for the project or service

  30. Project Deployment and Project Control Best Practices (VI) Note that once a decision has been made to terminate a project, the following tasks or core activities need to be implemented: • Hold termination close-out or postmortem meeting with project stakeholders • Re-allocate staff and resources back into the organization or originating teams • Work with finance team to close out the books and project binders for auditing purposes • Ensure that all classified data artifacts and access to facilities and accounts are closed • Hold a lessons learned meeting and document findings in PMO repository

  31. Project Closure best practices • When should a project be closed? Below is a project closure checklist PMs will find useful: • Ensure all project objectives and deliverables achieved and signed • Submit the final Project Closure Report to the Steering Committee • Ensure acceptance and endorsement of the Project Manager’s Project Closure Report by the Steering Committee • Clear the bills and close the Project Accounts • Ensure all other obligations met and closed • Send a Project Closure Message to everyone associated with the project • Disband the Project Team

  32. The Project Closure Report Project Closure best practices

  33. Compliance for Projects & Programs (I) • Why audit? An assessment or audit of a project or program is often undertaken to ensure the following: • Problematic cost, quality or schedule overruns • Litigation or legal reviews • Contract breach by contractors • Lessons learned • Poor deployment • Fraudulent activity

  34. Compliance for Projects & Programs (II) • Skills required to conduct auditing The following project or program skills are required by the person auditing a project or program: • Understanding of Project Methodologies and Life-cycles • Physical Security Skills • IT Security Skills • Financial Skills • Risk Management • Change management • Regulatory laws and compliance

  35. Compliance for Projects & Programs (III) • Overview on the Project Compliance Process a few key regulations of laws that impact many types of projects. • Sarbanes-Oxley • Gramm-Leach-Bliley • COBIT • HIPPA • ADA • Safe Harbor (EU) • Young Persons Policy • Environmental Policies

  36. Compliance for Projects & Programs (IV) The audit process can be divided into four fundamental activities: • Audit risk assessment • Audit planning • Audit fieldwork • Audit reporting

  37. Compliance for Projects & Programs (V) • Elements of the project audit Below are the key elements of a project audit. They include, but are not limited to: • Fulfillment of the project scope • Quality measures adopted • Quality report of the deliverable • Total costs incurred • Performance of the project team • Performance of the vendors and other external parties associated with the project • Risks encountered • Anomalies detected in the different project phases • Lessons learnt

  38. Reference • http://www.iappm.org/pdf/CIPAGuide_03Feb08.pdf

  39. Capability Maturity Models Integration(CMMI) 961643 楊智婷

  40. CMMI Introduction What is CMMI? • A process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance. • Developed by the Software Engineering Institute, SEI, at Carnegie Mellon. • CMMI defines what processes and activities need to be done. Purpose of CMMI • to help organizations improve their development and maintenance processes for both products and services.

  41. Continuous Representation

  42. Advanced Project Management Process Areas IPM=Integrated Project Management QPM = Quantitative Project Management RSKM = Risk Management

  43. Basic Project Management Process Areas PMC = Project Monitoring and Control PP = Project Planning SAM= Supplier Agreement Management

  44. Project Planning SG = Specific Goal SP = Specific Practice • SG 1 Establish Estimates • SP 1.1 Estimate the Scope of the Project • SP 1.2 Establish Estimates of Work Product and Task Attributes • SP 1.3 Define Project Lifecycle • SP 1.4 Determine Estimates of Effort and Cost • SG 2 Develop a Project Plan • SP 2.1 Establish the Budget and Schedule • SP 2.2 Identify Project Risks • SP 2.3 Plan for Data Management • SP 2.4 Plan for Project Resources • SP 2.5 Plan for Needed Knowledge and Skills • SP 2.6 Plan Stakeholder Involvement • SP 2.7 Establish the Project Plan • SG 3 Obtain Commitment to the Plan • SP 3.1 Review Plans That Affect the Project • SP 3.2 Reconcile Work and Resource Levels • SP 3.3 Obtain Plan Commitment

  45. Project Planning PMC Replan What to monitor What to build Engineering and Support process areas PP What to do Commitments Plans SAM Measurement needs PMC = Project Monitoring and Control PP = Project Planning SAM= Supplier Agreement Management

  46. Project Monitoring and Control • SG 1 Monitor Project Against Plan • SP 1.1 Monitor Project Planning Parameters • SP 1.2 Monitor Commitments • SP 1.3 Monitor Project Risks • SP 1.4 Monitor Data Management • SP 1.5 Monitor Stakeholder Involvement • SP 1.6 Conduct Progress Reviews • SP 1.7 Conduct Milestone Reviews • SG 2 Manage Corrective Action to Closure • SP 2.1 Analyze Issues • SP 2.2 Take Corrective Action • SP 2.3 Manage Corrective Action

  47. Project Monitoring and Control Status, issues, and results of process and product evaluations: measures and analysis Corrective action PMC Corrective action What to monitor Replan Status, issues, and results of reviews and monitoring Engineering and Support process areas PP SAM PMC = Project Monitoring and Control PP = Project Planning SAM= Supplier Agreement Management

  48. Supplier Agreement Management • SG 1 Establish Supplier Agreements • SP 1.1 Determine Acquisition Type • SP 1.2 Select Suppliers • SP 1.3 Establish Supplier Agreements • SG 2 Satisfy Supplier Agreements • SP 2.1 Execute the Supplier Agreement • SP 2.2 Monitor Selected Supplier Processes • SP 2.3 Evaluate Selected Supplier Work Products • SP 2.4 Accept the Acquired Product • SP 2.5 Transition Products

  49. Supplier Agreement Management Corrective action PMC = Project Monitoring and Control PP = Project Planning SAM= Supplier Agreement Management PMC Status, issues, and results of reviews and monitoring Engineering and Support process areas PP Plan SAM Product component requirements, technical issues, completed product components, and acceptance reviews and tests Supplier agreement Suppliers

More Related