ALB INTRO - PowerPoint PPT Presentation

Loading...

PPT – ALB INTRO PowerPoint presentation | free to view - id: 64f45a-Nzc4Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

ALB INTRO

Description:

Project Management Best Practice ISA Tech Talk Creggan Court Hotel, Athlone, 27th May 2008 Tech Talk Agenda Audience details. Audience Participation. – PowerPoint PPT presentation

Number of Views:25
Avg rating:3.0/5.0
Slides: 43
Provided by: LeoK4
Category:
Tags: alb | intro | goals | intranet

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: ALB INTRO


1
(No Transcript)
2
Project Management Best Practice
  • ISA Tech Talk
  • Creggan Court Hotel, Athlone, 27th May 2008

3
Tech Talk Agenda
  • Audience details.
  • 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 its 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
Why Projects Fail.
NEVER FROM A LACK OF EFFORT
  • 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
  • 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

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
  • Dont 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 ISCs.
  • Project Teams work to shorter objectives rather
    than long term goals.
  • Use ISCs to motivate and reward project team.
  • Use these ISCs 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 dont
    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
  • NASAs - 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_at_biokinc.com

42
(No Transcript)
About PowerShow.com