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 Topics Covered in ClassPMI Knowledge Areas Defining the ProjectProject Scope Management Estimating Project Times and CostProject Time Management Developing a Project PlanProject Cost Management Managing RiskProject Quality Management Scheduling Resources and CostsProject Human Resource Management Reducing Project DurationProject Communications Management Progress and PerformanceProject Risk Management Audit & ClosureProject Procurement Management Project Integration Management

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 Requirement Details LOCC001 Add a New blind to the account services page in MYCA to include a “Line Of Credit Management” link LOCC002 MYCA needs to evaluate eligible accounts to perform Line Reduction functions LOCC003 Add new links to the Line of Credit Reallocation Confirmation page in MYCA LOCC004 Add the Line of Credit Reduction functionality to MYCA LOCC005 MYCA to capture line Reduction application parameters LOCC006 MYCA will accommodate default/min/max values for the line Reduction amount LOCC007 MYCA needs to display Verification page for Line Reduction LOCC008 MYCA needs to forward Line Reduction requests to the Composite service to process a Line Reduction of card account LOCC009 MYCA needs to display Confirmation page for Line Reduction LOCC010 MYCA needs to display Error Messages after negative validations for the line reduction field are performed. LOCC011 LOCC011 –De Scope-BAU only needs to be included as a test condition LOCC012 SSP will revise the Minimum Line of Credit field

18. Business Requirements REQUIREMENT ID: LOCC003 DEFINITION: Add new links to the Line of Credit Reallocation Confirmation page in MYCA TYPE: Functional AS IS: Does not exist TO BE: MYCA needs to Add the following links to the Line of Credit Reallocation Confirmation page: 1.Balance Transfer. This link promotes card member to Balance Transfer transaction page. 2.Line of Credit Increase. Link to the line of credit input page. (Via additional authentication). NET CHANGE: New links in Line of Credit Reallocation Confirmation page in MYCA BENEFITS: - Increase LOC transactions by driving LOC Reallocation - Improve Card Member Navigation CONSTRAINTS: None identified at this time IMPORTANCE: High STAKEHOLDER: MYCA SPONSOR: AXPi risk METHOD OF CHANGE: Systematic

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