Project Management Best Practice

2. Project Management Best Practice ISA Tech Talk Creggan Court Hotel, Athlone, 27th May 2008

3. Tech Talk Agenda • Audiencedetails. • Audience Participation. • What is a project? • What is a successful project? • Why projects fail. • Best Practice Tips. • Case Study. • Standish Survey Results. • Summary.

4. Audience Details • How many people here work on projects. • Do you have a “Day” job or are projects what you do? • What type of projects do you work on? Large or Small, construction or IT or…………………… • Out of the people here working on projects - Who has formal Project Management training? • From the companies that you work for, which ones have formal PM practices/methodologies in place. • PM through the ages “The only certainty is that nothing is certain” Pliny the Elder (Roman Scholar) • Who said “Fail to Plan so Plan to Fail”? Old Military saying made famous in Ireland by Roy Keane, Saipan, World Cup 2006

5. Audience Participation From your experience executing projects, can you indicate reasons why you think that both large and small projects fail?

6. What is a project? PMI Definition of a project: A Project is a temporary endeavour undertaken to create a unique product, service or result. So this would indicate that a project is: Temporary – has a definite beginning and end so project team only exists for the project. Unique – Product/service or result is different from others of it’s kind.

7. What is a successful project?

8. What is a successful project? • Meets and satisfies all the Users or Organisations requirements. • All stakeholders are satisfied. • All close-out activities are complete. • Lessons learned have been documented. • Was completed on time. • Was completed to budget.

9. Poor Planning Unclear requirements Changing requirements (Scope Creep) No Project Manager No Risk Management Conflicts for resources No PM standards in place No vendor management No Change Control Lack of training Project not strategic No Post-Mortems on previous projects Poor Teamwork No User involvement Lack of communications No Management commitment Why Projects Fail. NEVER FROM A LACK OF EFFORT

10. Starting with the end in mind!

11. Starting with the end in mind! Project Management Truism There's never enough time to do it right first time but there's always enough time to go back and do it again!

12. Starting with the end in mind! • Plan, Plan, Plan and when you are finished planning, plan some more! • Agree requirements as early as possible then manage them using change control. • Get the right team in place to manage and execute the project. • Communicate, communicate, communicate. • Manage stakeholders expectations – always. • Put some PM procedures in place. • Get the user involved from the start.

13. Best Practice #1: Defining Scope/Requirements • Have scope/requirements planning sessions. • Ensure all stakeholders attend planning sessions. • Conduct interviews with “absent” stakeholders. • Hold “Requirements Review” sessions to ensure all expectations have been identified. • Manage “agreed” scope/requirements through change control. • Inform PM of all changes to scope/requirements.

14. Best Practice #2: Project Planning Project Management Truism The more you plan the luckier you get.

15. Best Practice #2: Planning – Is this a Project Plan?

16. Best Practice #2: Project Planning • Don’t start the project until you write a plan. • Plans require thinking, negotiation, balancing, communications and listening, so worth the effort. • Start the Risk Management process at the planning stage to identify uncertainty in the project. • Complete accurate Cost and Schedule estimates. • Build training time into the plan. • Plan time for project improvements.

17. Best Practice #2: Project Planning • Project Plan should include: • Description of the project, the approach to completing it and project objectives. • Work breakdown structure to substantial level • Cost, schedule and resource estimates. • Key milestones and target dates to complete. • Performance measurement. • Risk Management Plan including key risks • Scope Management Plan • Cost, Schedule, Quality & Communications Management Plan • ………..and more!

18. Best Practice #3: Define Success Points • Extended timelines lead to apathy and lost focus. Base on effort not calendars! • For large projects – Define “Intermediate success criteria (ISC)”. • Structure project schedules around ISC’s. • Project Teams work to shorter objectives rather than long term goals. • Use ISC’s to motivate and reward project team. • Use these ISC’s when reporting on project progress

19. Best Practice #4: User Involvement throughout • Critical to have user involvement throughout the scope definition process. • Users help define the “Actual” end requirements based on their understaning of how things work. • Lack of buy-in to the project if Users not involved. • Users motivation is in their involvement with the quality of the finished project. • Easier to get critical contributions throughout the project.

20. Best Practice #5: Stakeholder Management Project Management Truism Diplomacy is the art of letting other people have their way!

21. Best Practice #5: Stakeholder Management • Stakeholders are anyone positively or negatively impacted by your project (internal or external). • Identify ALL stakeholders as early as possible and determine ALL of their individual requirements. • All stakeholder requirements must be met (or negotiated!) to claim a successful project. • Stakeholders requirements will conflict and need to be managed by the PM. • Stakeholders expectations need to be managed through to the end of the project.

22. Best Practice #5: Stakeholder Management • Stakeholders can positively impact your project by providing support when you most require it (i.e. resources). • Communicate effectively with all stakeholders throughout the project (Gauge your effort!). • Different levels of stakeholders in an organisation will have different levels of influence on your project. Identify them and manage them!. • On project completion – get their opinions! • Know when to say “NO” to stakeholders.

23. Best Practice #6: Change Control • Initiate change control once requirements have been agreed. • Detail who is responsible for reviewing/approving changes. • Agree ALL the project impacts prior to approving. • Review Risk Logs each time a change is reviewed. • Never agree to changes without agreeing the impact on cost, schedule or resources. • Once agreed manage all changes to closure.

24. Best Practice #7: PM Methodology Project Management Truism Some projects finish on time in spite of project management best practices.

25. Best Practice #7: PM Methodology • A PM Methodology is not a pre-requisite for success but proceduralising some PM processes is. • There are many PM methodologies on the market but you do not need to implement one entirely. • Pick and choose aspects of a methodology which works for your projects and document it. • Ensure your PM processes are used across projects of varying complexity and size. • Continuously improve your processes with lessons learned on completed projects.

26. Best Practice #8: Communications Project Management Truism I know that you believe that you understand what you think I said, but I am not sure you realise that what you heard is not what I meant.

27. Best Practice #8: Communications • Team members work more effectively when they communicate with each other so: • Set up weekly communication sessions with the team. • Define project status reporting requirements up-front. Be honest with status reports. • Report progress/activities to all stakeholders. • Decide if you need a Communications Plan/Matrix? • Get stakeholders input into what info they want, how they want it presented, when and by who.

28. Best Practice #8: Communications Communications matrix

29. Best Practice #9: Automate where possible. • Large Projects - Use requirements tracking software to aid traceability. • Use collaborative workspaces to share information with the project team. Great for remote teams. • Use Intranet/Internet to share information with the wider project audience. • Use project scheduling applications to produce status reports. • Use technology to reduce manual tasks but don’t forget to use your Project Notebooks!!.

30. Best Practice #9: Automate where possible. • Project Management Tools for: • Developing Schedules. • Developing work breakdown structures • Managing team members time on a project. • Project status reporting • Risk Management. • Endless project. • Over 32 Million hits on Google so plenty to choose from.

31. Best Practice #10: Assign “Correct” Resources. • A Project Manager should be assigned by the Project Sponsor. Should be a leader, not just a manager. • PM should have negotiating, problem solving, flexibility, communications skills…………………. • “Line” resources should be agreed with Functional Managers (Planning of resources!!) • Project Team members should be identified through their qualifications and experience for all tasks. • Implement project specific training for the team.

32. Best Practice #11: Correct project environment. • Project Teams are not in it just for the money!! • Try to pick the most cohesive team available • Surveys suggest “rewarding work” and “being appreciated” are more important. • Allow Project Members to make mistakes (Once!) • Organise rewards for team success (night out!). • Ensure personal development is built into the project (Can I add this to my CV?!).

33. Best Practice #12: Project Post Mortems • Take time to carry out a post-project review. • Carry out during and as near to the end of the project as possible. • Document findings in a “Close-Out” Report. • Focus on what caused “project delays”. • Use the “Close-Out” report as an input to your next project. • File all “Close-Out” Reports centrally for all PMs

34. NASA Mars Orbiter 1999 • Orbiter disappeared en route to Mars. • No official Project Manager was assigned. • Two teams were involved in the development of the orbiter. • One team worked using the Metric system of measurement and one team worked using the Imperial system. • Results? Lack of scope definition, communications failures, lack of training and no systems approach used for complete mission NASA’s - Faster, Better, Cheaper replaced with Mission Success First.

35. Standish Survey Results • Survey conducted every year since 1994 in US. • Survey relates to IT projects only. • Project success is increasing year on year. • Project success is still incredibly low. Successful– Completed on time and within budget with all features included. Failed – Project aborted prior to completion. Challenged – Completed and operational projects which were over budget, over schedule and with reduced features.

36. Standish Survey Results Figure 1-1: Project outcomes history (1994-2000)

37. Standish Survey Results

38. Standish Report • No universal diagnosis why projects fail as all projects differ in size, complexity, people and circumstances. • Why do they Succeed? • User involvement. • PM had Management backing. • Scope was clear cut. • Expectations were realistic.

39. Summary • There are many reasons why projects fail and Massive effort is not one of them. • There are also many tools and techniques to ensure a project succeeds and not all are relevant to every project. • A good Project Manager is critical to project success. • Projects are always techically challenging but Organisations fail to realise they are huge social undertakings. • People make projects succeed through the application of knowledge, skills, tools and techniques. • Adopting a few techniques and tools will greatly enhance your projects possibility of success.

40. Reference Sources Web • www.pmi.org (Project Management Institute) • www.acentre.com(Some good PM psychology) • www.jiscinfonet.ac.uk (Mars Orbiter) Books • “A Guide to the Project Management Body of Knowledge” PMBOK Guide 3rd Edition. Software • Microsoft Project 2000

41. ANY QUESTIONS? For further Information on this presentation, contact: Karl.lawler@biokinc.com