Project Management

1. Project Management From the Classroom to the Boardroom

2. My Background • Undergrad at University of Guelph • Bank of Montreal • Operations -> Systems Programmer-> Project Mgr • AMEX • RBC • BMAK Business & Technology Consultants Inc • Implementing a procurement system for GOTT

3. Agenda • Share my experience as a Project Manager • A day in the life …….. • Expected outcome • You would have a better appreciation for the practical aspect of project management • Ask questions

4. Review of Topics Covered • Topics covered • Organization: Structure and Culture • Defining the Project • Estimating Project Times and Costs • Developing a Project Plan • Managing Risk • Scheduling Resources and Costs • Reducing Project Duration • Progress and Performance Measurement and Evaluation • Audit & Closure

5. Project Management Institute • Five process groups are  • Initiating • Planning • Executing • Controlling and Monitoring • Closing. • Nine knowledge areas: • Project Integration Management • Project Scope Management • Project Time Management • Project Cost Management • Project Quality Management • Project Human Resource Management • Project Communications Management • Project Risk Management • Project Procurement Management

6. Class  PMI

7. Opportunity • Federal Govt changes law to allow banks to issue more than 1 credit cards • Master Card issues a RFI • West Jet issues a RFI • RBC responds • Business cases done by all • Agree to partnership

8. Have a Project • What are the next steps ? • Initiate the project • Consistent processes, methodology • Everyone knows what to expect and what is expected from them • Frameworks • Templates

10. Software Development Methodology • Water Fall • Agile • Scrum

11. Organization Structure

14. Requirements • Business Analyst • Gathering business requirements may appear to be a simple process • Simply ask the user what they want • One of the most difficult and critical tasks • The quality and realism of the requirements gathering process is a primary ‘make or break‘ • If the requirements lack adequate definition, the project will fail to achieve its goals

15. Challenges • Communications gaps that exist between the business-savvy sponsor and the technical-minded • Executive instructs a subordinate to have IT develop a solution • IT enters the requirements gathering process with a preconceived (or pre-designed) solution and meets with the stakeholder out of courtesy • IT agrees with the sponsor on the definition of the requirements, and then begins working on the pre-designed solution, disregarding the input from the sponsor • The results of this situation are as predictable as they are historical. The sponsors do not receive a product that meets their needs and scope creep and poor design consume the project • For all practical purposes, the project fails

16. Project Definition • Objectives • RBC will issue MC by end of 2009 • RBC will include rewards features for WJ by end of 2009 • Scope Definition • What the project will deliver • User requirements • Product specs, if building a product

17. Scope Definition Business Requirements

18. Business Requirements

21. Relative Cost to fix problems

24. Quality Assurance • Responsible for guaranteeing a level of quality for the end client • Help the software development team to identify problems early in the process • Often known as "testers“ • More than just testing • Contributing to the quality of the final product

25. Quality Assurance (QA) Role • Focused on creating a quality deliverable • Responsibility of the QA role to make sure that the software development process doesn't sacrifice quality in the name of completed objectives

26. Quality Assurance (QA) Role • Works with the Functional Analyst (FA) and the Solutions Architect (SA) to convert the requirements and design documents into a set of testing cases and scripts • Used to verify that the system meets the client needs. • This collection of test cases and scripts are collectively referred to as a test plan • The test plan document itself is often simple providing an overview of each of the test cases • The testing cases and scripts are also used to validate that there are no unexplained errors in the system.

27. Types of Testing • Unit Testing • Assembly Testing • Integration Testing • Stress Testing • Load • Response time • Regression Testing

28. Test Case • A general-purpose statement that maps to one or more requirements and design points • It is the overall item being tested • It may be a specific usability feature • Technical feature that was supposed to be implemented as a part of the project • Test scripts fit into the test cases by validating that case • Test scripts are : • Step-by-step instructions on what to do • What to look for • What should happen • While the test cases can be created with nearly no input from the architecture or design, the test scripts are specific to how the problem was solved by the software development team and therefore they require an understanding of not only the requirements, but also the architecture, design, and detailed design.

29. Roles • Assist in creation of Requirements • SMART • Creates test cases and scripts. • Executes or supervises the execution of those test cases and scripts. • Facilitates or performs random testing of all components to ensure that there's not a random bug haunting the system

30. Risk Based Testing • Crashing the schedule • In theory, there is an infinite number of possible tests • RBT is a type of software testing that prioritizes the features and functions to be tested based on; • Priority/importance • Likelihood or impact of failure

31. Testing Tools • Load Runner • WinRunner • Mercury Quality Center

32. Administrative

33. Implementation Freeze code Pre-implementation Check Lists Test User Sign off Warranty

34. Tools – Status Report

35. Administrative

36. Thanks & Good Luck