Project Management 101

1. Project Management 101 Execution Phase       Video

2. Reviews • Concept Phase: • Completion of the Initiation Form • Completion of T-Shirt/Planning Statement of Work • Initiation Phase: • Project Manager is assigned. • Focuses on the high level documentation. • You will complete the High Level Plan, Communication Plan, Business Case/CBA and Statement of Work. • Planning Phase: • Focuses on detail level documentation. • You will complete your WBS session, Detail Work Plan, updated CBA and Statement of Work, RFP and/or Contract (if needed).

3. Execution Project Checklist

7. Project Team

8. 7 Habits of Highly Effective Teams Be proactive Begin with the end in mind Put first things first Think win/win Seek first to understand, then to be understood Synergize Sharpen the saw

9. Leading the Project Team To lead the team, a Project Manager must first act like a leader. They must care not only for the success of the project, but also for the success of the individuals on the team. Project leaders understand the value in listening to and addressing team members' concerns. They understand the importance of constructive criticism and showing gratitude. Project leaders inspire team members and strengthen teams.

10. Leaders vs. Managers Managers do things right; leaders do the right things. Management is science; leadership is art. They are two different talents. Managers deal with their team as resources; leaders deal with their team as humans.

11. Survival Island Split into 4 teams Your airplane has just crashed into the ocean. There is a desert island nearby and there is room on the life boat for each person plus 12 items (total) to survive on the island. Each team will decide, together, which items to take. Each team will share what they selected and why they selected each item.

12. Managing Stakeholder Expectations Managing stakeholder expectations is the process of communicating and working with stakeholders to meet their needs and addressing issues as they occur. The Project Manager is responsible for stakeholder expectations and management. Keeping an Issue Log is the best way to clearly communicate and categorize issues and manage expectations for stakeholders.

13. Managing Risks • Identify - Risk identification determines which risks might affect the project and documents their characteristics. • Analyze - Analyzing the identified risks will help the team identify which risk response method should be used. • Plan Responses - Risk response planning is essential to enhance opportunities and reduce threats to the project's objectives. • Monitor - New and changing risks will need to be monitored in order to ensure the successfulness of the project.

14. At what point does a risk become an issue? Video

15. Issues – Some Examples

16. What does a troubled project look like? Missed deadlines Increased budget Dissatisfaction within the ranks Missed milestones Sub-standard project team performance Sub-standard deliverable performance

17. Approach for Issue Management

18. Tips when issues arise

20. Low Normal High Critical Business Function General Project Staffing Technical Testing Audit

21. Variance Analysis Identify the differences between the work results and the estimates. Cost variance Schedule variance Determine what caused the variances (root cause) and plan a corrective action.

22. Root Causes Analysis - Review • Identify a problem, discover the underlying causes that lead to it and develop preventative action. • Fishbone • 5 Whys

23. Ishikawa (fishbone) Diagram- Lab

24. 5 Whys

25. Controlling Quality A lot of the quality checklists and metrics are baked into the methodologies. Quality management is simply making sure that the deliverables meet the methodology requirements. For example, the checklist for business requirements is that they are not ambiguous. If the requirements document contains requirements that are ambiguous, then the quality check has failed.

26. Baselines & Snapshots • There are 2 times during a project that the system will automatically take a snapshot of your Financial Summary and a baseline of your Work Plan. • When your High Level Plan is Approved • When your Detail Level Plan is Approved

27. Baseline Lab Baseline Lab  • Review your Baseline for your project. • Go to the Summary tab of your project. • In the Work Plan portlet, click the View Baselines button. • You will notice a baseline named High Level Business Case Approved. • Review the snapshot of your Financial Summary. • Go to the Summary tab of your project. • In the Project Cost portlet, select the View Financial Summary button. • Click the View Snapshots hyperlink in the Summary section.

28. Project Meetings • Weekly meetings to discuss the progression of the project and identify occurring roadblocks, risks and issues. • Types of Meetings • The Stand Up • Remote Team Check-In • Progress, Plans and Problems

29. What is going on with my project?

30. Status Meetings? In a poll, 50% of respondents said they would rather go to the DMV or watch paint dry than sit in a status meeting.

31. What does the Sponsor want to know? Does the Project Manager have control of what’s happening on the project? Any issues or problems that they need to be aware of so they will not be surprised down the road? Where are we today and what's the forecast costs and finish date? Do the team members understand what the PM expects of them?

32. The Stand Up- Most Important • Designed to Be: • Short: keep the meeting fast so people can get back to work. • Frequent: meet daily to make sure everyone has context for their work each day. • Tactical: focus on progress and what people are actually doing only, to encourage team accountability to each other and the plan. • Duration: 15 minutes or less. The shorter the better. • How it works: • Everyone stands up in a circle (if in the same place) or in front of their computers for a remote team. Each person takes turns answering three basic questions: • What did you do yesterday? • What will you do today? • Is there anything blocking your progress? • The team may ask a few questions, and assign someone to help with blocks raised during the meeting, but there should be no extended discussion. Fast, remember! • Best For: • Agile development teams • Teams that need more frequent calls to regain momentum and build trust • Teams complaining that meetings take too long.

33. Remote Team Check-In • Designed to Be: • All about asking and answering questions, instead of listening to reports. • Non-disruptive: weekly rather than daily. • Structured: always following the same pattern and time limits. • Duration: 25-50 minutes, depending on team size and how many questions there are. • How it works: • Once each week, the team provides written status updates. At meeting time, everyone joins the call and reads through the updates together. • After reading (silently to themselves) each person is given 5 minutes to ask questions about what they read. If a conversation goes long, those involved find a time to continue their discussion at another time. • Best For: • Teams with excellent written communication skills • Teams who use group chat and other ways to stay in touch during the week. • Teams of makers, those that really value lots of uninterruptedtime to focus.

34. Progress, Plans and Problems • Designed to Be: • A way to efficiently share a high level view of the business. • Held at weekly or longer intervals. • More conversational than the previous two. • Duration: 30-90 minutes depending on the number of reports and how frequent the group meets. • How it works: • Before every meeting, those reporting in will provide a written update answering these questions: • Progress: accomplishments since the last meeting. • Plans: goals and objectives for the next reporting period. • Problems: tasks you can’t finish because of blocks, dependencies or lack of knowledge. • Best For: • Teams who need some structure, but not rigid meeting rules. • Teams who meet less frequently.

35. How to run effective meetings Make the meetings routine – Put it on the calendar and don’t cancel it. Make an agenda (and stick to it) – Make sure it lists the purpose of the meeting, items to be discussed, time limits and who is leading the discussion. Try to send it ahead of time so people can come prepared to discuss materials or bring items if necessary. Make a parking lot board – Keep people on track; if people begin unrelated discussions, then remind them of the objectives and, if necessary, offer to put it on the parking lot board to be discussed later. Only invite key people – People who don’t have an interest or knowledge of the subject matter will throw you off track and slow you down. Keep minutes, record ideas, keep time Establish ground rules – Agree to listen to one another, respect and record all ideas, give everyone a chance to talk, make decisions by consensus, etc. Before wrapping up, ensure each decision has an action, that the relevant people take ownership of the decision and provide feedback of the action or progress at an agreed upon date.

36. Scope Management • What is scope management? • Checking to ensure that everyone is completing their work • Saying NO to additional work not in the charter • Preventing extra work/gold plating

37. Watch for Scope Creep We are NOT saying that functionality and features can not be added; we are saying that they cannot be added without first seeing how they will affect the cost, quality and schedule of the project. Use the Project Charter/SOW, WBS, Requirements documents, etc. to determine if something is in or out of scope.

38. Project Scope Change/SOW Revisions Lab Hand out

39. Managing Larger Project Scope For larger projects it may be smart to implement a Change Advisory Board (CAB) that would review potential changes to scope to make the decision on whether the change should be implemented.

40. Change Advisory Board (CAB) • The CAB is the group of individuals who participate in a cross-functional change review process representing the interests of their functional area. The CAB has the following responsibilities: • Understands the Change Management process and complies with its purpose. • Reviews proposed changes, the associated documentation and the proposed implementation schedules. • Reviews the Change Risk Analysis so as to understand the impact of changes to the project, the Enterprise System and their functional area. • Decides to accept or reject, or request additional information on the proposed scope changes.

41. Controlling Time/Schedule The project schedule should be analyzed on a weekly basis, at minimum, to determine if any corrective actions are needed to keep the schedule on track.

42. Controlling Costs Continuously forecast the budget – this should not only be done when you are writing the statement of work. Regularly forecast resource usage – ALL the time. Keep the team informed – it is the PM’s responsibility to inform the team members if they are getting close on their hours. Manage scope meticulously

43. Burn Down Tracker Lab Purpose: Creating a Burn down Pivot Table to monitor time coded to project versus SOW allocation. • Navigate to Search > Saved Searches > Find the search you saved. • Request Status = Waiting on SOW; Ready for Extract; Over Hours; Billed; Extracted; and Closed • In Billable field choose Blank; Yes; N/A • In SOW Request Number field; list the SOW Request Number you were assigned. • Select the Include Closed button toward the bottom right of the search • Click Search • Export to Excel – Delete the top 2 rows • Click Insert; Pivot Table; OK • In the quadrant ROW = Part Description • In the quadrant VALUES = Quantity (Sum) • Negative value = hours left on your SOW • Positive value = you have gone over your SOW ** This will work only if you have the negative numbers in the tool.

44. Time and Billing

45. Why we use T&B in PPM Tool • Although time is entered in PeopleSoft Time and Labor module, its current setup does not support the functionality needed to manage labor hours against projects and enhancements. • Through the PPM tool, we are able to manage labor hours including: • Tracking of labor hours against signed statement of work/work order. • Tracking of labor hours against project baselines. • PM/Shepherd approval of time entries. • Billing reports. • Biggest limitations of PPM tool • Since PPM tool is not the book of record for time entered, discrepancies found by the PM/Shepherd require user to update in PeopleSoft as well. • Time is uploaded bi-weekly effective 9/21/18, thus time is not reviewed by PM/Shepherd up to potentially 3 weeks after time is entered in PeopleSoft.

46. Time & Billing Workflow

47. Time & Billing Request Status’ • Approve Time • Time has been uploaded from PeopleSoft to PPM tool and pending review and approval from PM or Enhancement Shepherd • Not Approved • Time has been reviewed and there are discrepancies with the time entry • Discrepancies could include: • Employee coded against incorrect code • No knowledge of employee coding to your project and/or enhancement. • Employee has coded time after project and/or enhancement completion date.

48. Time & Billing Request Status’ • Cancel • Used infrequently; can be used if there is a duplication of time entries • Waiting on SOW • Time has been posted against a code in which we do not have a signed SOW/WO • As a rule and mandate from the COAO, work performed without a signed SOW is not allowed

49. Time & Billing Request Status’/Steps • Over Hours • Time has been posted against a code in which hours have exceeded the signed SOW/WO • Moving hours to this status means a revised SOW or work order will be created and sent to the agency to capture hours over along with any additional hours put towards the code. • If the intention is not to bill for hours over, seek approval from the Program Manager, then set the billable status to No and enter a reason/justification. • Button populates once time is approved and in Ready for Extract request status

50. Time & Billing Request Status’/Steps • Post Project Hours • Negative hours created by role from your signed SOW/WO • Negative hours can be pushed to this step once the below conditions are met: • PM or Shepherd confirms all time has been billed against code. • Everything is out of Approve time status except negative hours. • Project is in Ready for Audit status • Communication to project team to cease use of code