Lecture 2 by HC121106122550

VIEWS: 3 PAGES: 100

									                                 SE 477
     Software and Systems Project Management



             Dennis Mumaugh, Instructor
             dmumaugh@cdm.depaul.edu
             Office: CDM, Room 432
             Office Hours: Tuesday, 4:00 – 5:30




September 18, 2012                 SE 477: Lecture 2   1 of 100
                          Administrivia
   Comments and feedback
   PDF version of the Virtual case file exists here
    <http://condor.depaul.edu/dmumaugh/readings/handouts/SE477/FBI-
    VCF.pdf>.
   Tips for students
    (http://condor.depaul.edu/~dmumaugh/common/Tips_for_Non-
    CDM_Students.pdf)
   Mail
      Mailing list is enabled and active
   Access to tools [See notes or class web page for more info]:
      MicroSoft Project is accessible for students as part of the MSDNAA
        for DePaul students. There is an entry on the MyCDM page under
        resources.
      OpenProject is accessible for both Windows and Macintosh




September 18, 2012                  SE 477: Lecture 2                  2 of 100
                           Team Project
   Team Project
          Project is to develop a Recreation and Wellness Intranet Project.
          Get organized and start planning
   I will assign teams and set up the collaboration pages this
      coming weekend.
          I will form teams of about 5 people (no more); Teams will be mixed
           with each having least one Distance Learning student and one in-
           class student.
          There is a suggested template for the Project Plan/Report:
           http://condor.depaul.edu/~dmumaugh/se477/handouts/ProjectPlanTemplate.
           doc
   Look at the paper
          How to lose in SE 477



September 18, 2012                    SE 477: Lecture 2                      3 of 100
                     SE 477 – Class 2
   Topic: Software Project Management
       Software project management overview
       
        » Project managers
      Project organization
        » Putting a process in place
        » Software process
        » Phases for software project management
      Defining the project
        » Project charter
        » Statement of work (SOW)
        » Preliminary Scope
      Project management tools
  Reading:
      PMP Study Guide: Chapters 1-2
      Other texts on Reading List page

September 18, 2012              SE 477: Lecture 2   4 of 100
                     Thought for the day


                I am going to give you one advice about Project
                 Management … Projects Are About Humans.
                             Now Deal With That!




September 18, 2012               SE 477: Lecture 2                5 of 100
                               Last time
   Roadmap for Software Project Management;
   Fundamentals;
   4 Project Dimensions
          People, process, product, technology
     Software Process or What is a project?
     Project characteristics;
     Trade-off Triangle
     36 Classic Mistakes




September 18, 2012                   SE 477: Lecture 2   6 of 100
           The Growth of Project
         Management as a Profession




September 18, 2012   SE 477: Lecture 2   7 of 100
                PM History in a Nutshell
   Birth of modern PM: Manhattan Project (the bomb)
   1970’s: military, defense, construction industry
    were using PM software
   1990’s: large shift to PM-based models
          1985: TQM – Total Quality Management
          1990-93: Re-engineering, self-directed teams
          1996-99: Risk mgmt, project offices
          2000: M&A, global projects




September 18, 2012              SE 477: Lecture 2         8 of 100
                         The Field
   Jobs: where are they?
   Professional Organizations
       Project Management Institute (PMI) (pmi.org)
       
        » The Project Management Institute (PMI) is an
          international professional society for project managers
          founded in 1969
      Software Engineering Institute (SEI)
      IEEE Software Engineering Group
   Tools
      MS Project




September 18, 2012            SE 477: Lecture 2               9 of 100
            PMI & the PMP certification
   The Project Management Institute (PMI: http://www.pmi.org/) is the
      leading organization in advancing the project management profession
     Certifications
        PMI PMP
     The “PMBOK” – PMI Body of Knowledge
     PMI has more than 500,000 members in 185 countries–nearly double
      the number of members in spring 2008
     Provides support in:
        Education and training—seminars, program certification
        Professional development and networking—Global Congresses
        Professional standards and certification—standards for project-
          related activities (the PMBOK, scheduling, portfolios)
     The Project Management Professional (PMP) certification is amongst
      the most valuable certifications in the IT field


September 18, 2012                 SE 477: Lecture 2                     10 of 100
                     The Field Part 2
      Average PM salary $81,000
      Contract rates for PM’s can match techies
      PMI certification adds avg. 14% to salary
      PMI certificates, 1993: 1,000; 2002: 40,000
      Other cert: CompTIA Project+




September 18, 2012             SE 477: Lecture 2     11 of 100
                     The Project Manager
  The Role of the Project Manager
   Job descriptions vary, but most include responsibilities like
    planning, scheduling, coordinating, and working with people
    to achieve project goals
   Remember that 97% of successful projects were led by
    experienced project managers, who can often help influence
    success factors
  Skills for Project Managers
  Project managers need a wide variety of skills
   They should:
          Be comfortable with change
          Understand the organizations they work in and with
          Be able to lead teams to accomplish project goals

September 18, 2012                   SE 477: Lecture 2          12 of 100
Competencies for Project Managers
  1. People skills
  2. Leadership
  3. Listening
  4. Integrity, ethical behavior, consistent
  5. Strong at building trust
  6. Verbal communication
  7. Strong at building teams
  8. Conflict resolution, conflict management
  9. Critical thinking, problem solving
  10. Understands, balances priorities
  11. Negotiating
  12. Influencing the Organization
  13. Mentoring
  14. Process and technical expertise

September 18, 2012                SE 477: Lecture 2   13 of 100
        Software Project Management


                     Fundamentals




September 18, 2012    SE 477: Lecture 2   14 of 100
            Formal Project Management
   Advantages of Using Formal Project
     Management
    Better control of financial, physical, and human resources
    Improved customer relations
    Shorter development times
    Lower costs
    Higher quality and increased reliability
    Higher profit margins
    Improved productivity
    Better internal coordination
    Higher worker morale (less stress)
           Less “death marches”
           Less overworked personnel

September 18, 2012                 SE 477: Lecture 2         15 of 100
     What Helps Projects Succeed?*
   1. Executive support                        7. Firm basic
   2. User involvement                            requirements
   3. Experienced project                      8. Formal methodology
      manager                                  9. Reliable estimates
   4. Clear business                           10.Other criteria, such
      objectives
                                                  as small milestones,
   5. Minimized scope                             proper planning,
   6. Standard software                           competent staff, and
      infrastructure                              ownership

                     *The Standish Group, “Extreme CHAOS,” (2001).

September 18, 2012                    SE 477: Lecture 2              16 of 100
     Conventional Software Management Performance
  Barry Boehm’s “Industrial Software Metrics Top 10 List”:
   Finding and fixing a software problem after delivery costs
    100 times more than finding and fixing the problem in early
    design phases
   You can compress software development schedules 25%,
    but no more
   For every $1 you spend on development, you will spend $2
    on maintenance
   Software development and maintenance costs are primarily
    a function of source lines of code.
   Variations among people account for the biggest difference
    in software productivity; hire good people to succeed.


September 18, 2012           SE 477: Lecture 2              17 of 100
     Conventional Software Management Performance
  Barry Boehm’s “Industrial Software Metrics Top 10 List”:
   The overall ratio of software to hardware costs is still
    growing.
   Only about 15% of software development effort is devoted
    to programming
   Software systems and products typically cost 3 times as
    much per SLOC as individual software programs. Software
    system products (system of systems) costs 9 times as much
   Walkthroughs catch 60% of the errors
   80% of the contributions comes from 20% of the
    contributors.



September 18, 2012          SE 477: Lecture 2            18 of 100
                       First Principles
   One size does not fit all
   Spectrums
          Project types
          Sizes
          Formality and rigor




September 18, 2012               SE 477: Lecture 2   19 of 100
                         Strategy
                     Hope is not a strategy.

  So what is our strategy?
   Classic Mistake Avoidance
   Development Fundamentals
   Risk Management
   Schedule-Oriented Practices




September 18, 2012           SE 477: Lecture 2   20 of 100
              PMI’s 9 Knowledge Areas
     Project integration management
     Scope
     Time
     Cost
     Quality
     Human resource
     Communications
     Risk
     Procurement




September 18, 2012           SE 477: Lecture 2   21 of 100
    Project Management Framework




September 18, 2012   SE 477: Lecture 2   22 of 100
                     IT project life cycles
   IT projects have two concurrent life cycles:
          Project life cycle (PLC) encompasses all activities of
           project, including the System/Software Development Life
           Cycle (SDLC)
          PLC is directed toward achieving project requirements
          SDLC is directed toward achieving product requirements
   Both life cycle models are needed to manage an IT project
          PLC alone will not adequately address system
           development concerns
          SDLC alone will not adequately address business and
           product integration concerns


September 18, 2012              SE 477: Lecture 2              23 of 100
                     Project Life Cycles
  What is a project life cycle?
   All projects are divided into phases
   All phases together are known as the Project Life Cycle
   Each phase is marked by completion of Deliverables
   Identify the primary software project phases:
      Requirements
      Analysis
      Design
      Construction
      Quality Assurance (aka Testing)
      Deployment



September 18, 2012           SE 477: Lecture 2                24 of 100
            What is a project life cycle?
       Consists of a number of generally sequential phases
       Phases are defined by technical information transfer or technical
        component hand-off
       Cost and staffing levels vary as a function of time according to the
        following qualitative schematic diagram:




September 18, 2012                  SE 477: Lecture 2                       25 of 100
            What is a project life cycle?
   Risk of failure is greatest at start of project when the level of
    uncertainty is highest
   Stakeholder influence over project product decreases as
    project continues
   Project life cycles define:
      Technical work to be done in each phase
      When deliverables are to be generated in each phase
      How each deliverable is reviewed, verified, and validated
      Who is involved in each phase
      How to control each phase
      How to approve each phase



September 18, 2012              SE 477: Lecture 2                26 of 100
             Phases in project life cycle
    The completion and approval of one or more deliverables (measurable,
     verifiable work product) defines a project phase
    In iterative systems development, new phase can be started without
     closing the previous phase
    A phase can be closed without initiating subsequent phase




September 18, 2012                SE 477: Lecture 2                  27 of 100
           Project & product life cycles




September 18, 2012     SE 477: Lecture 2   28 of 100
      Software Development Process
   Ad hoc
       Code and Fix
       
      Rapid Prototyping
   Prescriptive
      Linear (Classic and Waterfall)
      Evolutionary (Iterative/incremental or spiral)
      Unified Process
   Adaptive
      Lean and agile methods




September 18, 2012             SE 477: Lecture 2        29 of 100
   Waterfall system development model
    The traditional (aka waterfall) Software Development Life
       Cycle (SDLC)




September 18, 2012            SE 477: Lecture 2              30 of 100
                     Project Phases A.K.A.




September 18, 2012           SE 477: Lecture 2   31 of 100
   Waterfall system development model
   Highly-sequential process
   Failure symptoms:
       Protracted integration and late design breakage
      Late risk resolution
      Requirements-driven functional decomposition
      Adversarial stakeholder relationships
      Focus on documents and review meetings
   Still followed (in name or practice) by many organizations,
    usually a modified version




September 18, 2012            SE 477: Lecture 2              32 of 100
Iterative system development model
   Non-linear approach to system development
   Incorporates top five principles of modern development
      processes:
        Architecture first. Provides the central design element
        Iterative life-cycle process. Provides the essential risk
         management element
        Component-based development. Provides the
         technology element
        Change management environment. Provides the control
         element
        Round-trip engineering. Provides the automation element




September 18, 2012             SE 477: Lecture 2              33 of 100
    5,000 foot view of Iterative SDLC
                             Iterative SD model
                                defines four life-cycle
                                phases:
                                 Inception
                                  

                                Elaboration

                                Construction

                                Transition

                             We iterate through each
                              phase, and repeat as
                              needed.
                             Now, for a quick survey of
                              the phases…

September 18, 2012   SE 477: Lecture 2                    34 of 100
                      Inception phase
   Essential activities
          Formulate product scope. Capture requirements and
           operational concept
          Perform feasibility analysis. Determine whether the
           organization has the resources and technical capabilities
           to meet customer’s needs
          Synthesize the system architecture. Evaluate essential
           system design constraints and trade-offs, as well as
           available solutions
          Plan and prepare business case. Address risk
           management, staffing, iteration plans, cost, and
           infrastructure


September 18, 2012               SE 477: Lecture 2               35 of 100
                     Elaboration phase
   Most critical phase of the four
   Essential activities
          Elaborate the vision. Detail elements of the vision that
           drive architectural or planning decisions
          Elaborate the process and infrastructure. The
           construction process and environment are established
           here
          Elaborate the architecture and select reusable (internal
           or COTS) components. Baseline the architecture as
           quickly as possible and demonstrate that the architecture
           will support the vision at reasonable cost in reasonable
           time



September 18, 2012               SE 477: Lecture 2              36 of 100
                     Construction phase
   Essential activities
          Achieve useful versions (intermediate, alpha, beta, and
           other test releases)
          Perform resource management, control, and process
           optimization
          Complete component development and test
          Assess product releases against acceptance criteria




September 18, 2012               SE 477: Lecture 2               37 of 100
                     Transition phase
   Essential activities
          Perform deployment-specific engineering tasks.
           Commercial packaging and production, sales kit
           development, field personnel training
          Assess deployment baselines against complete vision
           and acceptance criteria. Examine and compare what is
           being delivered to what was envisioned and delineated
           by acceptance criteria




September 18, 2012              SE 477: Lecture 2             38 of 100
        Comparative expenditure profiles
                     Waterfall                                       Iterative

      Activity                   Cost                    Cost                  Activity

      Management                 5%                      10%                   Management

      Requirements               5%                      10%                   Requirements

      Design                     10%                     15%                   Design

      Code & Unit Testing        30%                     25%                   Implementation

      Integration & Test         40%                     25%                   Assessment

      Deployment                 5%                       5%                   Deployment

      Environment                5%                      10%                   Environment

      Total                      100%                   100%                   Total

                                               Based on and adapted from Tables 1-1 and 10-1 in
                                               Software Project Management: A Unified Approach by Walker Royce


September 18, 2012                      SE 477: Lecture 2                                                39 of 100
                     Project Managers
   Growing demand for software project managers
       Organizations have become customer-driven.
       
      Organizations have evolved from function to process
       structures.
      Organizations are using task forces more frequently.
      Organizations have become more project-oriented.
   From the organization perspective, project managers are
    needed to:
      Gain market share
      Be first to market
      Stay profitable
      Maintain Quality


September 18, 2012          SE 477: Lecture 2             40 of 100
                     Project Managers
   Project Managers are mainly responsible to all issues
    related to the software project; issues may vary depending
    on the project scale, some of the common issues are:
      Schedule
      Budget
      Quality
      Delivery of products
      Locking resources
   Bottom line, as a project manager you will notice that most
    of your time is consumed chasing and collecting the status
    of project tasks.



September 18, 2012           SE 477: Lecture 2               41 of 100
         Understanding Organizations
    Structural frame: Focuses          Human resources
    on roles and responsibilities,     frame: Focuses on
    coordination and control.          providing harmony
    Organization charts help           between needs of the
    define this frame.                 organization and needs
                                       of people.

    Political frame: Assumes           Symbolic frame: Focuses
    organizations are coalitions       on symbols and meanings
    composed of varied                 related to events. Culture is
    individuals and interest           important.
    groups. Conflict and power
    are key issues.

September 18, 2012              SE 477: Lecture 2                 42 of 100
              Organizational Structures
   Functional
       Engineering, Marketing, Design, etc
       
      P&L from production
   Projectized
      Project A, Project B
      Income from projects
      PM has P&L responsibility
   Matrix
      Functional and Project based
      Program Mgmt. Model
      Shorter cycles, need for rapid development process




September 18, 2012          SE 477: Lecture 2               43 of 100
                 Functional Organization




    Pros                                       Cons
       – Clear definition of authority           – “Walls”: can lack customer
       – Eliminates duplication                  orientation
       – Encourages specialization               – “Silos” create longer decisions
       – Clear career paths                      cycles
                                                 – Conflicts across functional areas
                                                 – Project leaders have little power


September 18, 2012                       SE 477: Lecture 2                     44 of 100
                Projectized Organization




       Pros                                    Cons
           – Unity of command                       – Duplication of facilities
           – Effective intra-project                – Career path
           communication

                     Examples: defense avionics, construction

September 18, 2012                     SE 477: Lecture 2                          45 of 100
                     Matrix Organization




      Pros                                      Cons
         – Project integration across             – Two bosses for personnel
         functional lines                         – Complexity
         –Efficient use of resources              – Resource & priority conflicts
         –Retains functional teams

September 18, 2012                      SE 477: Lecture 2                     46 of 100
                        Matrix Forms
   Weak, Strong, Balanced
   Degree of relative power
          Weak: functional-centric
          Strong: project-centric




September 18, 2012               SE 477: Lecture 2   47 of 100
Organizational Structure – Influences on Projects


          Organization Type                                           Matrix
    Project                    Functional       Weak Matrix      Balanced          Strong Matrix     Projectized
    Characteristics                                              Matrix
    Project Manager's          Little or        Limited          Low to            Moderate          High to
    Authority                  None                              Moderate          To High           Almost Total
    Percent of Performing
    Organization's             Virtually        0-25%            15-60%            50-95%            85-100%
    Personnel Assigned Full-   None
    time to Project Work
    Project Manager's Role     Part-time        Part-time        Full-time         Full-time         Full-time
    Common Title for           Project          Project          Project           Project           Project
    Project Manager's Role     Coordinator/     Coordinator/     Manager/          Manager/          Manager/
                               Project Leader   Project Leader   Project Officer   Program Manager   Program Manager
    Project Management
    Administrative Staff       Part-time        Part-time        Part-time         Full-time         Full-time




                                                                                       PMBOK Guide, 2000, p. 19


September 18, 2012                                    SE 477: Lecture 2                                            48 of 100
                                    Process
   A process encapsulates an organization’s experience in form of
    successful recipes.
   Process descriptions, generally, contain the sequence of steps to be
    executed, who executes them, the entry/exit criteria for major steps, etc.
   Guidelines, checklists, and templates provide support to use the
    processes.


                                             Processes



                      Checklists              Guidelines        Templates



           Activity                Review

September 18, 2012                      SE 477: Lecture 2                 49 of 100
             Putting a Process in Place
   Choosing a Process.
          All projects have a process, unfortunately some don’t specify and
           implement their process.
          Projects with no specified process end up thrashing.
          Thrashing, unproductive work, can quickly cripple a project.
   Generally, there are two choices for choosing a process:
       1. Tailor the organizational process to your project.
           » Used when most of the people are from the same group as
               before
           » Used when the last project was successful.
       2. Specify a process for your project.
           » Good when people are from different organizations using
               different processes



September 18, 2012                   SE 477: Lecture 2                     50 of 100
                     Tailoring a Process
   Steps to Tailoring an Organizational Process:
       1. Determine how your project differs from the typical
          organizational project.
       2. Form two lists: activities your project needs from the
          organizational process and tasks your project doesn’t
          need from the process
       3. Propose changes to the organizational process
       4. Circulate the tailored process within the team and other
          key personnel for review and input.
       5. Integrate the changes and move quickly for closure.




September 18, 2012             SE 477: Lecture 2               51 of 100
                     Assessing the Process
   Assessing should be an ongoing process through out the project.
   Both the project and the process should lend themselves to assessment
    and improvement.
   Make gathering measurements part of concurrent documentation.
   Gather data to answer the following:
      Were the tasks and supporting activities effective?
      How much effort did each task and activity require?
      What tasks and activities were performed but weren’t in the process
       specification?
      How did the products change over time?
      When did tasks and activities start and stop?
      How did tasks and activities integrate?
      When in the project did we spend effort doing what?
   Repeat this during project close out.

September 18, 2012                SE 477: Lecture 2                   52 of 100
  The Project Manager: Responsibilities
     Project planning
     Managing the project
     Lead project team
     Building client partnerships
     Targeting to the business




September 18, 2012              SE 477: Lecture 2   53 of 100
                               Few Rules Before We Embark
   And finally, communicate, communicate, and communicate!
     Communication Effectiveness




                                                                                   people in a
                                                                                   conference
                                                                                   room with
                                                                                   whiteboard
                                                                             people
                                                                             on Video
                                                                             Conferencing

                                                                          phone
                                                        Videotape
                                   Paper     email




                                   Richness of communication channel

September 18, 2012                                    SE 477: Lecture 2                          54 of 100
                           Recap
  Definition of a Project
   A project is a sequence of unique, complex, and connected
    activities having one goal or purpose and that must be
    completed by a specific time, within budget, and according
    to specification.
  What is a Program?
   A program is a collection of projects.
   The projects must be completed in a specific order for the
    program to be considered complete. Because they
    compromise multiple projects, they are larger in scope than
    a single project.



September 18, 2012           SE 477: Lecture 2              55 of 100
                     Project Parameters
   Five constraints operate on every project:
       Scope
       
      Quality
      Cost
        » Time
        » Resources
   A change in one of these constraints can cause a change in
    another constraint to restore the equilibrium of the project
   Let’s discuss each one of these in detail …




September 18, 2012           SE 477: Lecture 2              56 of 100
                     Scope




September 18, 2012   SE 477: Lecture 2   57 of 100
                     Project Parameters
  Scope
   Scope is a statement that defines the boundaries of the project. It tells
    not only what will be done but also what will not be done.
   In the information systems industry, scope is often referred to as a
    functional specification.
   In the engineering profession, it is generally called a statement of work.
  Quality
   Two types of quality are part of every project:
      The first is product quality. This refers to the quality of the
        deliverable form of the project.
      The second type of quality is process quality, which is the quality of
        the project management itself. The focus is on how well the project
        management process works and how can it be improved.
        Continuous quality improvement and process quality management
        are the tools used to measure process quality.

September 18, 2012                 SE 477: Lecture 2                     58 of 100
                     Project Parameters
  Cost – The X-amount of dollars that it will cost to do the project is another
    variable that defines the project; the budget that has been established
    for the project.
        This is an important factor for projects that create deliverables that
         are sold to external customers
  Time – The customer specifies a timeframe within which the project must
     be completed.
        Cost and time are inversely related to one another. The time a
         project takes to be completed can be reduced, but cost increases as
         a result.
   Resources – Resources are assets, such as people, equipment, physical
     facilities, or inventory, that have limited availabilities, can be scheduled,
     or can leased from an outside party. Some are fixed, others are variable
     only in the long term. In any case, they are central to the scheduling of
     project activities and the orderly completion of the project.

September 18, 2012                    SE 477: Lecture 2                       59 of 100
    5,000 foot view of PM processes
                             PMBOK Guide collects the forty-
                              four defined PM processes into
                              five Project Management
                              Process Groups
                                 Initiating

                                 Planning

                                 Executing

                                 Monitoring & Controlling

                                 Closing

                             Now, we’ll take a quick survey of
                              the processes in each group …




September 18, 2012   SE 477: Lecture 2                     60 of 100
 Phases of the Project Management
   There are five phases of the project management life cycle:
       Scope/Define/Initiate – Scope the project
       
      Plan – Develop the project plan
      Execute – Launch the plan
      Monitor – Monitor/control project progress
      Close – Close out the project
   Note: these can be repeated for each phase
   Each process/phase/activity is described by:
      Inputs
      Tools & Techniques
      Outputs



September 18, 2012           SE 477: Lecture 2              61 of 100
                     Initiating Process
   Develop project charter
       State the problem/opportunity.
       
      Concerned with authorizing a project
      May be used for a whole project
      May be used for a single project phase in a large, multiphase project
   Develop preliminary project scope statement
      Concerned with producing a preliminary, high-level definition of
       project
      Broadly defines what is and what is not part of the project
   Establish the project plan.
      Define the project objectives.
      Identify the success criteria.
      List assumptions, risks, obstacles




September 18, 2012                 SE 477: Lecture 2                    62 of 100
                     Initiating Process
   Inputs
      Product Description
       
     Strategic plan
     Project Selection Criteria
     Historical Information
   Outputs
     Project Charter
     Project Manager assigned
     Constraints
     Assumptions




September 18, 2012          SE 477: Lecture 2   63 of 100
                     Planning Process
    Devising and maintaining a workable scheme to accomplish the business
      need that the project was undertaken to address

    Scope Planning                          Risk Planning
    Scope Definition                        Schedule Development
    Activity Definition                     Quality Planning
    Activity Sequencing                     Communications Planning
    Activity Duration                       Organization Planning
     Estimating                              Staff Acquisition
    Resource Planning                       Procurement Planning
    Cost Estimating                         Project Plan Development
    Cost Budgeting

September 18, 2012                SE 477: Lecture 2                  64 of 100
                Develop the project plan
   Develop project management plan
         Concerned with creating and integrating all sub-plans into a single
          source of information
        Identify the project activities.
     Scope planning
        Concerned with how the project scope statement will be created
     Create WBS
     Scope definition
        Concerned with actual creation of project scope statement
     Activity definition
        Activity sequencing
        Activity duration estimating
        Activity resource estimating
     Determine resource requirements.

September 18, 2012                   SE 477: Lecture 2                     65 of 100
                     Planning processes
   Schedule development
        Concerned with analyzing activity outputs (definition, etc.) to create
         project schedule
     Construct/analyze the project network.
     Cost estimating **
     Cost budgeting
        Concerned with aggregating costs of individual activities to establish
         cost baseline
     Quality planning *
        Concerned with quality standards and how to achieve them
     Human resource planning *
     Communications planning *
                                                     * indicates minimal or no coverage
                                                     ** indicates optional coverage



September 18, 2012                   SE 477: Lecture 2                                66 of 100
                     Planning processes
   Risk identification
   Risk management planning
        Concerned with how to carry out risk management activities
     Qualitative risk analysis
        Concerned with prioritizing risks based on probability of occurrence
         and impact
     Quantitative risk analysis *
     Risk response planning
        Concerned with mitigating risks to project objectives
     Plan purchases and acquisitions *
        Concerned with what, when, and how of purchases and acquisitions
     Plan contracting *
     Prepare the project proposal.



September 18, 2012                  SE 477: Lecture 2                    67 of 100
                     Executing Process
    Coordinating people and other resources to carry out the plan
       Project Plan Execution            Identify and organize the
       Scope Verification                   project team.
       Quality Assurance                   Establish team operating
       Acquire project team                 rules.
       Team Development                    Level project resources.
       Information Distribution            Schedule work packages.
       Solicitation                        Document work packages.
       Source Selection
       Contract Administration


September 18, 2012                 SE 477: Lecture 2               68 of 100
    Monitoring & Controlling Process
    Ensuring that project objectives are met by monitoring and measuring
      progress and taking corrective measures when necessary


      Overall Change Control             Establish progress reporting
      Scope Change Control                  systems.
      Schedule Control                     Install change control
      Cost Control                          tools/process.
      Quality Control                      Define problem-escalation
                                             process.
      Performance Reporting
                                            Monitor project progress versus
      Risk Response Control                 plan.
                                            Revise project plans.




September 18, 2012                 SE 477: Lecture 2                       69 of 100
      Monitoring & Controlling Process
   Monitor and control project work
         Concerned with acquiring and assessing performance information to
          effect process improvements
     Integrated change control
     Scope verification
        Concerned with acceptance of project deliverables
     Scope control
        Concerned with changes to project scope
     Schedule control
        Concerned with changes to project schedule
     Cost control *
        Concerned with changes to the project budget
     Perform quality control
        Concerned with monitoring quality compliance of project results and
          correcting unsatisfactory results
September 18, 2012                 SE 477: Lecture 2                    70 of 100
      Monitoring & Controlling Process
   Manage project team
        Concerned with tracking performance, providing
         feedback, and coordinating changes
     Performance reporting *
        Concerned with status, progress, and forecasting
     Manage stakeholders
     Risk monitoring and control
     Contract administration *




September 18, 2012            SE 477: Lecture 2             71 of 100
                     Close out the project
  Formalizing acceptance of the project or phase and bringing it to an orderly
     end
   Administrative Closure
       Concerned with finalizing all activities across all Process Groups
       Complete project documentation.
       Complete post-implementation audit.
         » Lessons learned
       Issues final project report.
   Contract Close-out
       Concerned with completing and settling all contracts
       Obtain client acceptance.
       Install project deliverables.




September 18, 2012                  SE 477: Lecture 2                     72 of 100
 Phases of the Project Management
  Level of Activity and Overlap of Process Groups Over Time




September 18, 2012          SE 477: Lecture 2                 73 of 100
   Project Processes & Their Integration
   Project Management Processes (Principles of Project Management)
       Initiating processes (Defining)
      Planning processes
      Executing processes
      Monitoring & controlling processes
      Closing processes
   System Development Processes
      Inception phase
      Elaboration phase
      Construction phase
      Transition phase
   Integrating IT Project Processes
      PM/IT project integration tactics




September 18, 2012               SE 477: Lecture 2                    74 of 100
      PM/IT process integration tactics
   Wherever possible, establish common policies, processes,
      and procedures between IT and PM groups
     Identify an integration manager to link IT and PM groups
     Use a common, integrated, consistent vocabulary that is
      continuously updated to facilitate inter- (as well as intra-)
      group communications
     Ensure that project manager possesses suitable process
      integration skills and is familiar with IT risks
     Involve IT analysts in development of business
      requirements
     Identify an ombudsman to quickly resolve issues that arise
      between PM and IT groups


September 18, 2012              SE 477: Lecture 2                75 of 100
    Phases in iterative* system life cycle


                         Engineering Stage                                       Production Stage




                                                                                                                          Phases
             Inception                    Elaboration               Construction                    Transition




                                        Establish the                  Build the
                                                                                                Roll out a fully-
                                           ability to                intermediate
        Establish that the                                                                        functional
                                       build the system           internal releases
        system is viable                                                                        system to the
                                             within                      of the
                                                                                                  customer
                                          constraints                   system



                                                                    Intermediate
               Idea                       Architecture                                                Product
                                                                      Releases


     * I often interchange iterative & evolutionary



September 18, 2012                                        SE 477: Lecture 2                                         76 of 100
                         Project & SDLC integration
                        waterfall development model




                                                                                                                                  Waterfall SDLC Phases
                                                                                                         Deployment



       Concept          Requirements          Design           Code & Unit Testing      Integration & Test




                                                                                                                              PM Process Groups
           Initiating                  Planning                             Executing                        Closing


                                                       Monitoring & Controlling




September 18, 2012                                     SE 477: Lecture 2                                               77 of 100
                                Project & SDLC integration
                                   iterative development model
                        Engineering Stage                                                      Production Stage


          Inception                       Elaboration                      Construction                               Transition

                                          Establish the                         Build the
                                                                                                                      Roll out a fully-
       Establish that the                    ability to                       intermediate
                                                                                                                        functional
       system is viable                  build the system                  internal releases
                                                                                                                      system to the
                                               within                             of the
                                                                                                                        customer
                                            constraints                          system




                                                                                                                                                      PM Process Groups
          Initiating                        Planning                                   Executing                                    Closing


                                                            Monitoring & Controlling




                                                                           Intermediate
             Idea                        Architecture                                                                     Product
                                                                             Releases



                            Objectives                      Architecture                        Initial Operational                       Product
                            Milestone                        Milestone                         Capability Milestone                       Release
                                                                                                                                          Milestone




September 18, 2012                                              SE 477: Lecture 2                                                               78 of 100
                     Initiating the Project




September 18, 2012          SE 477: Lecture 2   79 of 100
                     Initiating the Project
     Define scope
     Document Project Risks, Assumptions, and Constraints
     Identify and Perform Stakeholder Analysis
     Develop Project Charter
     Obtain Project Charter Approval
     Deliverables
        Project charter
        Statement of work (SOW)




September 18, 2012           SE 477: Lecture 2               80 of 100
                     Preliminary Scope
     Project objectives
     Product description
     Deliverables
     Constraints
     Assumptions
     Project acceptance criteria




September 18, 2012             SE 477: Lecture 2   81 of 100
             Interactions / Stakeholders
   As a PM, who do you interact with? Project Stakeholders

     External people                        Team
            Project sponsor                          Architects
            Executives                               System Engineers
            Customers                                Designers
            Contractors                              Developers
            Functional managers                      Testers
            Users                                    Documenters




September 18, 2012                 SE 477: Lecture 2                      82 of 100
         Key project stakeholder roles
     Project manager. Responsible for managing project
     Customer. Person or organization that acquires product
     User. Person or organization that uses product
     Performing organization. Organization performing work of
      project
     Project team members. Individuals performing work of
      project
     Project management team. Individuals directly involved in
      project management activities
     Sponsor. Entity providing financial resources for project
     Influencers. Entities indirectly affecting project
     PMO. Project management office


September 18, 2012             SE 477: Lecture 2              83 of 100
       Software System Stakeholders
  Each stakeholder has different concerns:

    Customer         Manager         Architect             Developer     Tester
                                    Maintainability    Components
   Requirements      Cost           Portability                        Functionality
                                                       Connectors
   Cost              Schedule       Feasibility                        Requirements
                                                       Class/Pattern
   Schedule          Requirements   Reusability                        Regression
                                                       Data flow
   Performance       Process        Extensibility                      Tools
                                                       Reuse
   Reliability       Resources      Flexibility                        Simulators
                                                       Flexibility
   Security
                                    The ilities        Extensibility




September 18, 2012                     SE 477: Lecture 2                          84 of 100
                      Stakeholder Triad
  1. Function Representative
          The ‘business person’
          Or SME: Subject Matter Expert
  2. Executive Sponsor
          Project’s visionary & champion
          Also the ‘General’, ‘Fall Guy’, and ‘Minesweeper’
          Not the PM, ‘Santa Claus’, or the ‘Tech Guy’
  3. Project Manager
          The ‘Linchpin’
          Must be ‘multi-lingual’


September 18, 2012                   SE 477: Lecture 2         85 of 100
                     Define the Project
   There is a need for clear understanding of exactly what is to
     be done. Project definition starts with the Conditions of
     Satisfaction document based on conversation with the
     customer.
   Project Overview Statement aka Charter or Vision is
     generated from the Conditions of Satisfaction document.
   The Project Overview Statement clearly states what is to be
     done.
   Once the Project Overview Statement is approved, the
     scoping phase is complete.
  In most cases the Project Overview Statement, the Statement
     of Work, and Project Charter are the same. Even scope will
     fit here. We will use them interchangeably.

September 18, 2012            SE 477: Lecture 2              86 of 100
                        Project Charter
   The Conditions of Satisfaction statement provides the input we need to
      generate the Charter.
     The Charter is a short document that concisely states what is to be done
      in the project, why it is to be done, and what business value it will
      provide to the organization when completed.
     The main purpose of the Charter is to secure senior management
      approval and the resources needed to develop a detailed project plan.
     It will be reviewed by the managers who are responsible for setting
      priorities and deciding what projects to support. It is also a general
      statement, it is not detailed technical statement.
     A high-level project description:
         Business need, product, assumptions
     Often precedes SOW
     Often 2-4 pages (can be longer)



September 18, 2012                  SE 477: Lecture 2                    87 of 100
                      Project Charter
   Typical outline
          Overview
            » Business need
               • Problem/opportunity
            » Objectives
               • Project goal
            » Method or approach
          General scope of work
            » Success criteria
          Rough schedule & budget
          Roles & responsibilities
          Assumptions, risks, obstacles
September 18, 2012              SE 477: Lecture 2   88 of 100
             Statement of Work (SOW)
   A description of the work required for the project; normally this is used
      when the project is being contracted out, but most of this is part of the
      Project Overview or Charter
     Sets the “boundary conditions”
     SOW vs. CSOW (Contract SOW)
        Latter: uses legal language as part of a competitive bidding scenario
     Can be used in the final contract – be careful, be specific, be clear
     Typically done after approval (after “Go”)
     Can be multiple versions
       1. List of deliverables for an RFP
       2. More detailed within final RFP
       3. Binding version from contract




September 18, 2012                   SE 477: Lecture 2                     89 of 100
                            SOW Template
    I.      Scope of Work: Describe the work to be done to detail. Specify the hardware and
            software involved and the exact nature of the work.
    II.     Location of Work: Describe where the work must be performed. Specify the
            location of hardware and software and where the people must perform the work
    III.    Period of Performance: Specify when the work is expected to start and end,
            working hours, number of hours that can be billed per week, where the work must
            be performed, and related schedule information. Optional “Compensation”
            section.
    IV.     Deliverables Schedule: List specific deliverables, describe them in detail, and
            specify when they are due.
    V.      Applicable Standards: Specify any company or industry-specific standards that
            are relevant to performing the work. Often an Assumptions section as well.
    VI.     Acceptance Criteria: Describe how the buyer organization will determine if the
            work is acceptable.
    VII.    Special Requirements: Specify any special requirements such as hardware or
            software certifications, minimum degree or experience level of personnel, travel
            requirements, documentation, testing, support, and so on.

September 18, 2012                          SE 477: Lecture 2                                 90 of 100
 S.M.A.R.T. characteristics for Goal
   Doran’s S.M.A.R.T. characteristics provide the criteria for a
      goal statement:
          Specific: Be specific in targeting and objective.
          Measurable: Establish measurable indicator(s) of progress.
          Assignable: Make the object assignable to one person for
           completion.
          Realistic: State what can realistically be done with available
           resources.
          Time-related: State when the objective can be achieved; that is,
           duration




September 18, 2012                    SE 477: Lecture 2                       91 of 100
 The Project Definition Statement : PDS
   Just as the customer and the project manager benefit from
    the Charter, the project manager and project team can
    benefit from a closely related document, which we call the
    Project Definition Statement (PDS).
   The PDS uses the same form as the Charter but
    incorporates considerably more detail. The detailed
    information provided in the PDS is for the use of the project
    manager and the project team.




September 18, 2012            SE 477: Lecture 2               92 of 100
            Project Management Tools




September 18, 2012   SE 477: Lecture 2   93 of 100
            Project Management Tools
  There are many tools available
   MS-Project is an example of these tools
   Basic requirements
      Develop a Work Breakdown Structure
      Build network diagram (aka PERT chart)
      Build Gantt chart
      Assign resources
      Calculate critical path and critical chain
   What is the difference between critical path and critical
    chain?
      Critical chain also manages buffer activity durations and
       resources

September 18, 2012            SE 477: Lecture 2              94 of 100
                     PM Tools: Software
   Low-end
       Basic features, tasks management, charting
       
      MS Excel, Milestones Simplicity
   Mid-market
      Handle larger projects, multiple projects, analysis tools
      MS Project (approx. 50% of market)
   High-end
      Very large projects, specialized needs, enterprise
      AMS Realtime
      Primavera Project Manager




September 18, 2012            SE 477: Lecture 2                95 of 100
Work Breakdown Structure




                           1.   Breaks project into a hierarchy.
                           2.   Creates a clear project structure.
                           3.   Avoids risk of missing project
                                elements.
                           4.   Enables clarity of high level planning.
                     Tools: Gantt Chart




September 18, 2012          SE 477: Lecture 2   97 of 100
                Tools: Network Diagram




September 18, 2012       SE 477: Lecture 2   98 of 100
                          Next Class
   Topic:
    Project Planning
             The Project Management Plan;
             Scope Management;
             Creating the Work Breakdown Structure (WBS)
   Reading:
    PMP Study Guide: Chapters 3-4
    Other texts on Reading List page
   Assignment: due next week
    Paper: case study on the FBI’s Virtual Case File


September 18, 2012              SE 477: Lecture 2           99 of 100
                     Journal Exercise
   What is the difference between a technical manager
    (supervisor) and a project manager.
   Can a project have both (or possibly several technical
    managers)?
   Is it possible for a technical manager to be the project
    manager as well (and do a good job with both roles)?




September 18, 2012            SE 477: Lecture 2                100 of 100

								
To top