Docstoc

Project Management Skills

Document Sample
Project Management Skills Powered By Docstoc
					IS Project Management

      Project Plan
        Purpose of project plan
• The purpose of a project plan is to maintain
  control of a project.
• As a complicated process, a project always
  threatens to exceed the limit of your control.
• Some people are better than others at
  controlling complex problems, but all of us
  reach our limits at some stage.
• To maintain control you need help in the form
  of tools and your best tool is your plan.
Project plan controls the project by
• Breaking a complex process down into a number of
  simpler components
• Providing visibility for obscure or ambiguous tasks in
  the project
• Providing a single point of reference for everyone
• Enforcing scrutiny of the sequence and nature of
  events
• Providing a baseline against which execution of the
  project can be compared
• Anticipating likely events and providing pre-planned
  means of avoiding them.
       Project planning includes
• Estimating the attributes of the work products
  and tasks,
• Determining the resources needed,
• Negotiating commitments,
• Producing a schedule,
• identifying and analysing project risks.
The project plan provides the basis for
performing and controlling the project’s project
activities that address the commitments with
the project’s customer
         Project plan contents (1)
•   Purpose/background/approach
•   Goals/objectives
•   Scope
•   Deliverables
•   Constraints/assumptions
•   Related projects/critical dependencies
         Project plan contents (2)
•   Schedule and milestones
•   Budget/cost-benefit assessment
•   Risk assessment
•   WBS
•   Quality management approach
•   Tools and techniques to be used
         Project plan contents (3)
•   Resource estimates
•   Standards
•   Change and control procedures
•   Roles/responsibilities
•   Work plan
•   Communications
•   Team contact directory
•   Approval sign-off form
   Purpose/background/approach
• State the purpose of the Project Plan. Indicate in
  a short statement that the Plan will provide a
  definition of the project, including the business
  goals and objectives
• Briefly describe the project history. Include
  information such as previous initiatives, business
  environment changes (may be related to
  competition, regulation, resource availability),
  and the impetus and rationale for the
  project. Describe, in essence, how the project
  came about.
Project planning: Overall approach
• The project plan should set out the overall approach
  you will take to achieve the objectives you have set.
   – Strategy and/or methodology How you will achieve the
     objectives
   – Issues to be addressed List any important issues
     highlighted in the programme circular/ITT and say how
     they will be addressed (e.g. interoperability, collaboration,
     evaluation)
   – Scope and boundaries Clearly indicate what will and will
     not be covered
   – Critical success factors List 3-4 factors which are
     important for the project to be successful
  Business Goals and Objectives
• Goal:
  – A goal is an aspiration of the company that states
    a direction in which the company will focus its
    efforts in support of its mission.
• Objective:
  – Objectives are short-term targets (typically 12-24
    months or less) of defined, measurable
    achievement.
     Projects goals and objectives
• State the goals and objectives expected to be achieved
  as a result of implementing the project, and describe
  how meeting them will support the corporate
  objectives and goals.
• Set project objectives by establishing why the project
  has been commissioned and what it is expected to
  achieve for the enterprise. Identify the specific results
  to be realized and the benefits to be achieved. Be
  certain to establish the time frame in which the
  objectives are expected to be met. Define a visible
  method to monitor and measure progress in meeting
  the objectives.
                          Scope
• A clear and concise definition of scope is key to the success
  of any project.
• Scope should describe from a quantitative perspective
  what is to be accomplished. Its purpose is to aid in
  establishing realistic work plans, budgets, schedules, and
  expectations.
• Should identified work arise that falls outside the defined
  scope, the Project Manager must either deem the work out
  of scope and defer it, or expand the scope of the project to
  include the work.
• The latter choice would result in formal changes to the
  work plan, resource allocation, budget and/or schedule.
                 Deliverables
• Project Products may include formal deliverables
  as well as informal concrete results.
• Include in this section a list of the deliverables
  and their contents (if appropriate) to be
  produced during the project.
• Detailed descriptions of each deliverable may be
  contained within the Appendix.
• Including a detailed list of deliverables in the
  Appendix provides a structured approach which
  ensures that all persons involved in the project
  understand what is expected.
          For each deliverable
• Name and description
• Purpose
• Major task(s) producing/updating the
  deliverable
• Expected audience
• Sign-off participants
          Project assumption
• Briefly describe any assumptions made about
  the project related to resources, scope,
  expectations, schedules, etc. Assumptions
  should be specific and measurable.
     Sample project assumptions
• Project staff resources will be available when and
  as they are needed.
• Required hardware resources will be available
  when and as they are needed.
• Equipment order lead times are known and can
  be expected to be met.
• No outside consulting will be required or Outside
  consulting will be limited to a specified number
  of days at a specified rate per day.
           Project constraints
• Describe the principal constraints and
  limitations under which the project must be
  conducted, concerning the project
  environment or parameters (timeframes and
  deadlines, funding, skill levels, resource
  availability, etc.).
            Related projects
• List any other projects that are impacted by
  the project described in the Plan. Managers
  of related projects should be kept in the
  communication loop on all matters related to
  this project.
           Critical dependencies
• It is essential that the dependencies between related
  tasks and subtasks be understood to ensure that tasks
  are sequenced correctly and that the critical path of a
  project is recognized.
• Determine the relationship between work performed
  in a given task or subtask with the work performed in
  other tasks or subtasks. Identify the predecessor and
  successor activities.
• Identify any tasks within a related project on which this
  project is dependent and describe the relationship.
       Schedule and milestones
• We plan major project milestones, the special
  and most important points of our project time
  line. In project implementation phase, the
  project milestone plan will enable us to
  control the progress on the highest level of
  schedule.
• Schedule is further refined using network
  diagrams and project management software
                            Budget
• Provide a detailed breakdown of the necessary
  resource budgets for each of the major work activities
  in the WBS.
• Specify the estimated cost for activity personnel, and
  include as appropriate, the costs for the following
  items:
   –   travel,
   –   meetings,
   –   computing resources,
   –   software tools,
   –   special testing and simulation facilities, and
   –   administrative support.
                 Risk assessment
•   Risk description
•   Status
•   Date identified
•   Project phase
•   Functional assignment
•   Risk trigger
•   Probability of occurrence (percent)
•   Impact ($ or days)
•   Response actions
•   Responsibility (task manager)
                          WBS
• First developed by the US Defense Department in the
  second half of the 1950s and by NASA in the early 1960s, a
  Work Breakdown Structure is a document used by project
  managers to define the scope of a project.
• It describes the end goal, not the means of reaching that
  goal. F
• or example, if the project is to build a house, the WBS
  defines all the aspects of the finished house, in increasing
  levels of detail.
• It does not specify how the elements of the house are to be
  constructed, except where the method of construction is an
  important part of the finished house.
             WBS shows you
• What the various elements of the project are
• How the necessary work is distributed
  between the elements of the project
• How the cost or budget is distributed between
  the elements of the project
• How the larger elements of the project are
  subdivided into smaller ones
           Creating a WBS (1)
• Define the project’s end product. This is
  usually no more than a title: “House at
  Avenue Drive” for example. It forms the root
  of the Work Breakdown Structure document.
           Creating a WBS (2)
• Define the main deliverables.
• These are the main components of the
  project’s end product, for example, for a
  house, External construction, Internal
  construction, and so on.
• These become sections or ‘main branches’
  under the root, defined in the previous step.
             Creating a WBS (3)
• Break down the main deliverables into their sub-
  components using as many sub-branches as needed
  until you have manageable ‘units of work’ which do
  not need to be subdivided further.
• These units of work should be of a size that the project
  manager can easily handle.
• For example, something that a worker or a team of
  workers can accomplish in a week might represent a
  unit of work.
• Too much subdivision is counter productive as the
  project manager will then have to get too involved in
  the project details.
          100 % rule PMI definition
• The 100% Rule...states that the WBS includes 100% of the work
  defined by the project scope and captures ALL deliverables –
  internal, external, interim – in terms of the work to be completed,
  including project management. The 100% rule is one of the most
  important principles guiding the development, decomposition and
  evaluation of the WBS. The rule applies at all levels within the
  hierarchy: the sum of the work at the “child” level must equal 100%
  of the work represented by the “parent” and the WBS should not
  include any work that falls outside the actual scope of the project,
  that is, it cannot include more than 100% of the work… It is
  important to remember that the 100% rule also applies to the
  activity level. The work represented by the activities in each work
  package must add up to 100% of the work necessary to complete
  the work package.
                      WBS
• Work Breakdown Structure (WBS) is a
  fundamental project management technique for
  defining and organizing the total scope of a
  project, using a hierarchical tree structure.
• The first two levels of the WBS (the root node
  and Level 2) define a set of planned outcomes
  that collectively and exclusively represent 100%
  of the project scope.
• At each subsequent level, the children of a parent
  node collectively and exclusively represent 100%
  of the scope of their parent node.
 WBS outcomes instead of actions
• Outcomes are the desired ends of the project,
  such as a product, result, or service, and can
  be predicted accurately.
• Actions, on the other hand, may be difficult to
  predict accurately. A well-designed WBS
  makes it easy to assign any project activity to
  one and only one terminal element of the
  WBS.
                WBS 100% rule
• Once the basic layout of the Work Breakdown
  Structure is complete, we add numbers to indicate the
  percentage of the total work that the various elements
  of the project represent.
• These percentage numbers are ideally added to the
  branches that are lowest in the hierarchy (furthest
  from the root), but if that proves too detailed they can
  be entered on intermediate branches.
• The important thing is that they should add up to
  100% at the root, which represents the work for the
  whole project.
    The Four Elements in Each WBS
               Element


1. The scope of work, including any
   “deliverables.”
2. The beginning and end dates for the scope of
   work.
3. The budget for the scope of work.
4. The name of the person responsible for the
   scope of work.
    Mutually-exclusive Elements
• It is important that there is no overlap in
  scope definition between two elements of a
  WBS.
• This ambiguity could result in duplicated work
  or miscommunications about responsibility
  and authority. Likewise, such overlap is likely
  to cause confusion regarding project cost
  accounting
    Quality management approach
•   Activity Reviews/Walk-throughs
•   Tools and Techniques
•   Test Approach
•   Performance/Quality Standards
•   Quality Management Roles
 Activity Reviews/Walk-throughs
• Identify the types of project reviews and walk-
  throughs that will be conducted. Include
  items such as test plans and test scripts to be
  reviewed. Indicate when reviews should occur
  in relation to other tasks.
         Tools and Techniques
• List and briefly describe the tools and
  techniques that will be used on the project to
  ensure quality. Tools may include specific
  software packages for project scheduling,
  testing, etc
              Test Approach
• Briefly describe the approach that will be used
  to test the project results prior to putting
  them into production. All products developed
  as a result of the project should be tested.
 Performance/Quality Standards
• Identify any performance or quality standards
  which must be met upon approval of the final
  results of the project. This may include
  acceptance criteria for the final work product.
     Quality Management Roles
• Define the specific quality management roles
  and their accompanying responsibilities that
  individuals will be assigned to ensure quality
  on the project.
    Tools and techniques to be used
•   Project management tools
•   Development environment
•   Test tools
•   Software engineering tools
    Change and control procedures
• Change Control Process must recognise the
  reality that some change will be essential but
  too much change can cause project failure.
  Before the project starts the change control
  procedure must be designed. An important
  element of this is deciding who will be
  authorised to spend the sponsor's money on
  changes during the project.
           Change Control Process
                                    Change Control                            Rejected changes
                                                                                are returned to
  Problem report or
                                     Business Decision                      Initiator and saved for
enhancement request
                                                                               Future reference
( internal or customer)




 Request
   for                    Feasibility review
 change                                                   Change Implementation
                           Impact analysis
                                                         Detailed Implementation plan

                                                                        Change
                                                                         Notice

                                    Master Document                           Product
                                         control                             or service
                                   Update documentation                 Update product or service
A change control system should include all
              the following
• Procedures to handle changes that may be approved
  without prior review
• Procedures for automatic approval of defined
  categories of change
• Paperwork, tracking systems, and approval levels
  necessary for authorising changes
• A description of the powers and responsibilities of
  the change control board
     Change control and Configuration
              Management
• Needed to keep project in control
• Key responsibility of project manager
• Requires documentation and management of
  baseline plan
• Requires systematic approach to changing the
  baseline plan
           Resource estimation

• Resource estimation is a structured prediction
  of the cost and other resources required to
  execute a task.
• One of the primary functions of the process is
  to establish a control basis.
• Therefore the more accurate the estimation,
  the more reliable the control system becomes.
                    Work plan
• Work plan is a document that states what activities,
  jobs and tasks should be done to achieve identified
  goals and objectives with reference to available funds,
  human resources, and time.
• Work plan is similar to implementation plan and it
  often becomes a part of project plan.
• A work plan for project allows performing project
  tasks and jobs by following schedules and timelines
  identified in project plan.
• Work plan is a detailed description of how employees
  should do tasks and jobs .
               Project Standards
• Identify standards agreed to by the Project Team that
  govern the way in which the project will be
  conducted. Such standards include status reporting, staff
  meetings, product review acceptance criteria, and
  celebration criteria.
• Describe which standards, if any, already exist within the
  enterprise and are appropriate for reuse on the project.
• Such reusable standards typically include project model
  management, technology, documentation management
  and training techniques, naming conventions, quality
  assurance, and testing and validation. These may be
  standards that are recognized and embraced by the
  industry as a whole, or those that are unique to the
  enterprise.
           Project communications
• Describe the roles and responsibilities of each Team Member along
  with the communication plan to ensure that Team Members
  understand what is expected of them. Describe the mechanism for
  communicating responsibilities across the Project Team and within
  the organization at large (to the extent that it is required).
• Develop a specific strategy that promotes communication among
  Team Members if the Project Team is geographically dispersed,
  including how each Team Member will report progress specific to
  each assigned task.
• Identify how progress on the project will be determined and how it
  will be communicated to those involved in or impacted by the
  project. Identify how often status reports will be distributed and to
  whom. Determine how often progress meetings will be held and
  who is expected to attend.
         Roles/responsibilities
• Define the roles filled by project team
  members and the responsibility of each role.
  Project Team Contact Directory
• This is a list of all Team Members and other
  individuals involved in or impacted by the
  project.
• The list should include their names, physical
  locations, phone numbers, alternative contact
  numbers, User-IDs, Mail Stops, home addresses,
  titles, and any other pertinent information that
  will enable better communication between the
  impacted individuals.
          Approval sign-off form

• Sign-off must be obtained each time the
  Project Plan is revised.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:1/4/2013
language:English
pages:56