1. Is This A Good Project? KEY POINTS TO LOOK FOR WHEN AUDITING AN IT PROJECT WMISACA June 16 2016 Brian Jennings, PMP

2. What is a Project? Per Project Management Institute (PMI) Project Management Body Of Knowledge (PMBOK) a project is: A temporary endeavor undertaken to create a unique product, service or result. So if every IT project is “unique”, how to you have a standard measure to tell how they are doing? You don’t, but there is a framework you can use - PMBOK

3. The PMBOK COBIT Business Based Framework Stakeholder Value and Business Objectives PMBOK Provides guidelines for managing individual projects Ten Knowledge Areas and five Process Groups Not all applied equally to all projects

4. Process Groups

5. Knowledge Areas Integration Scope Management Time Management Cost Management Quality Management Human Resource Management Communications Management Risk Management Procurement Management Stakeholder Management

6. Gartner Gartner studied more than 50 projects that are on the public record as having experienced complete failure, have been seriously compromised or have overrun their IT budgets significantly. The analysis showed that the organisation’s refusal to address complexity in the business process is the main reason. Complex projects with unrealistic goals, unproven teams and almost no accountability at all levels of the management and governance structure, means no one is responsible for failure.

7. Gartner This means that when a program manager or product owner is assigned to lead the project, that project head must also be given the appropriate authority to make decisions in that capacity. Assignment of decision rights means the assignment of accountability and responsibility for making decisions and for managing the risks associated with those decisions. The take-away message is that you should simplify everything about the project, and ensure that the program manager/owner has the responsibility, accountability and authority to get the job done.

8. Project Smart https://www.projectsmart.co.uk/most-it-projects-fail-will-yours.php Project Initiation and Planning Issues Unclear or unconvincing business case Insufficient or non-existent approval process Poor definition of project scope and objectives Insufficient time or money given to project Lack of business ownership and accountability Insufficient and/or over-optimistic planning Poor estimating Long or unrealistic timescales; forcing project end dates despite best estimates Lack of thoroughness and diligence in the project startup phases

9. Project Smart Technical and Requirements Issues Lack of user involvement (resulting in expectation issues) Product owner unclear or consistently not available Scope creep; lack of adequate change control Poor or no requirements definition; incomplete or changing requirements Wrong or inappropriate technology choices Unfamiliar or changing technologies; lack of required technical skills Integration problems during implementation Poor or insufficient testing before go-live Lack of QA for key deliverables Long and unpredictable bug fixing phase at end of project

10. Project Smart Stakeholder Management and Team Issues Insufficient attention to stakeholders and their needs; failure to manage expectations Lack of senior management/executive support; project sponsors not 100% committed to the objectives; lack understanding of the project and not actively involved Inadequate visibility of project status Denial adopted in preference to hard truths People not dedicated to project; trying to balance too many different priorities Project team members lack experience and do not have the required skills Team lacks authority or decision making ability Poor collaboration, communication and teamwork

11. Project Smart Project Management Issues No project management best practices Weak ongoing management; inadequately trained or inexperienced project managers Inadequate tracking and reporting; not reviewing progress regularly or diligently enough Ineffective time and cost management Lack of leadership and/or communication skills

12. What to look for Larger project will be different from a smaller project The larger the project, in general, more detail and more knowledge areas The larger the project, the more formal the processes Project Charter Project Schedule / Tasks to granularity appropriate for project Formal Process and Procedures Monitoring / Status Reporting Clear roles, responsibilities and accountability Clear business need / ROI / etc. Acceptance and ability to deal with Risk Business not heavily involved

13. What to look for Scope creep Lack of communication Lack of upper management commitment Unrealistic planning / schedule / commitments Pressure from above Failure to plan is planning to fail

14. One Hundred Rules for NASA Project Managers Rule 1: A project manager should visit everyone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work and the best proof is for the manager to visit them and see first hand what they are doing. Rule 5: Vicious, despicable, or thoroughly disliked persons, gentlemen, and ladies can be project managers. Lost souls, procrastinators, and wishy-washies can not. Rule 6: A comfortable project manager is one waiting for his next assignment or one on the verge of failure. Security is not normal to project management. Rule 15: The seeds of problems are laid down early. Initial planning is the most vital part of a project. The review of most failed projects or project problems indicate the disasters were well planned to happen from the start.

15. One Hundred Rules for NASA Project Managers Rule 17: Talk is not cheap; but the best way to understand a personnel or technical problem is to talk to the right people. Lack of talk at the right levels is deadly. Rule 18: Most international meetings are held in English. This is a foreign language to most participants such as Americans, Germans, Italians, etc. It is important to have adequate discussions so that there are no misinterpretations of what is said. Rule 36: Hide nothing from the reviewers. Their reputation and yours is on the line. Expose all the warts and pimples. Don't offer excuses, just state facts. Rule 56: The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists. Rule 100: Never make excuses; instead, present plans of actions to be taken.

16. Questions?