Docstoc

PROJECT MANAGEMENT

Document Sample
PROJECT MANAGEMENT Powered By Docstoc
					PROJECT MANAGEMENT
    Lecture Notes 2
     PROJECT MANAGEMENT
• Software Project Managements is an
  umbrella activity within Software Engineering

• Project Management involves the Planning,
  Monitoring and Control of People, Process
  and Events that occur as Software evolves
  from preliminary concept to an operational
  implementation.
•
  Project Management begins before any
  technical activity and continues throughout
  the Definition, Development and Support of
  Computer Software.
       PROJECT MANAGEMENT
• WHO DOES IT ? Project Managers
  .Project Managers Plan, Monitor and Control the work of Team of
  Software Engineers.


• WHY IS IT IMPORTANT ?

 Building a Computer Software is a complex undertaking, particularly if it
  involves many people working over a relatively long time. That’s why
  Software Projects need to be Managed.


• WHAT IS THE WORK PRODUCT ?                         ‘’A PROJECT PLAN’’

  Project Plan defines the Process and Tasks to be conducted, the People
  who will do the work and the mechanism to assessing Risks, Controlling
  Change and Evaluating Quality.

  Project Plan is produced as Management activities commences
        THE MANAGEMENT SPECTRUM
Effective Project Management focuses on 4 P’s

        People, Product , Process, Project

• A Manager who forgets that Software Engineering is an intensely
  Human endeavour will never have success in Project Management.

    Manager who fails to encourage comprehensive Stakeholders
   communication early in the evolution of a Project Risk building an
   elegant solution for the wrong problem

• The Manager who pays little attention to the Process runs the risk of
  inserting competent technical Methods and Tools into a vacuum.

• The Manager who embarks without a solid Project Plan jeopardize
  the success of the Product.
       THE 4’Ps OF PROJECT MANAGEMENT
1. THE PEOPLE
• The People Factor is so important that Software Engineering
  institution has developed a People Management Capability Maturity
  Model. (PM-CMM).

• PM-CMM Defines the following key practice areas for Software
  People:-

     - Recruiting
        - Selection
           - Performance Management
               - Training
                  - Compensation
                       - career Development
                           - Organization and work Design
                              - Team Culture Development

• Organizations that achieve high level of Maturity in People
  Management area have a higher likelihood of implementing effective
  Software Engineering Practices.
       THE 4’Ps OF PROJECT MANAGEMENT
THE PRODUCT (Software Application )

• Before a Product can be Planned:-
  - Product Objectives and Scope should be Planned

  - Alternative solutions should be considered
   - Technical and Management Constraints should be identified.

• Without the PRODUCT Plan it is not possible to define:-

    a) Reasonable and accurate Estimates of Cost and
       Effective Risk Management
    b) Realistic breakdown of Project tasks (WBS)

    c) Project Schedule that provides a meaningful indication of
       progress.
        THE 4’Ps OF PROJECT MANAGEMENT
THE PROCESS

• Software Process provides the Framework from which a
  comprehensive Plan for Software Development can be established.

• A small number of Framework activities are applicable to all
  Software Projects regardless of Project size or complexity.

• A number of Different Task set however, such as :-
         - Tasks
            - Milestones
                - Work Product (Deliverables)
                    - Quality Assurance points
  enables the Framework activities to be adapted to the
  characteristics of the Software Project and the requirements of the
  Project team.
        THE 4’Ps OF PROJECT MANAGEMENT
THE PROJECT

• Software Project Development is conducted in a Planned and
  Controlled way since it is only known way to manage complexity.
  And yet we still struggle.

• In 1998 industry data indicated that 26% of Project failed outright
  and 46% experienced Cost and Schedule overruns.
  Although Project success rate for Projects has improved, yet Project
  failure rate remains higher than it should be!

WHY PROJECTS FAIL
   - An unrealistic Deadlines is established
   - Changing Customer Requirements
   - An honest underestimate of effort
   - Predictable and/ or unpredictable risks
   - Miscommunication among project staff
   - Failure in Project Management practice
      THE 4’Ps OF PROJECT MANAGEMENT
THE PROJECT

• AVOIDING PROJECT FAILURE

   - Project Managers and Software Engineers must:-
   - Heed a set of common warning signs
   - Understand the Critical Success Factor (CFS) that
     lead to good Project Management
   - Develop a common sense approach for
     Planning, Monitoring and controlling a Project.
          THE 4’Ps OF PROJECT MANAGEMENT
THE PEOPLE AS PROJECT PLAYERS (STAKEHOLDERS)

• The Software Process is populated by People as Players or
  otherwise called as Stakeholders. Who can be categories into one of
  the Five constituencies:-

     -    Senior Mangers
     -    Project Managers
     -    Software Engineers (Practitioners)
     -    Customers or Clients
      -   End-users

• Since the Software Process is populated by People. The Project
  Teem must be organized in a way to maximize each person’s skills
  and ability. The Organization of the Project Team is the Job of
  Project Team Leader may be called Project Manager.

• Companies that organizes and Manages their people wisely .
  Prosper in the long run!!!
    THE 4’Ps OF PROJECT MANAGEMENT
TEAM LEADERS

• Project Management is a people-intensive
  activity, and for this reason, competent
  Software Practitioners often make poor
  Team Leaders since they do not have the
  right mix of people skills

• Many Practitioners unfortunately just fall
  into a Project Manager role and become
  accidentally Project Mangers.
        TEAM LEADERSHIP
TECHNICAL LEADERSHIP

• Jerry Weinberg suggests a Technical Leadership Model
  (MOI). Based on Motivation, Organization and Ideas
  (Innovation)
•
  Weinberg also suggests that successful Project Leader
  applies a Problem Solving Management Style.

PROBLEM SOLVING MANAGEMENT STYLE

•   Concentrate on understanding the Problem to be
    solved;

• Managing the flow of ideas and at the same time letting
  everyone on the Project team (by word or action) that
  quality counts and that it will not be compromised.
                       TEAM LEADERSHIP
CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANAGER

    •   PROBLEM SOLVING
    •   MANAGERIAL IDENTITY
    •   ACHIEVEMENT
    •   INFLUENCE AND TEAM BUILDING

PROBLEM SOLVING

• An effective Project Manager can diagnosis Technical and organizational
  issues that are most relevant;

• Systemically structure a solution or properly motivate other Software
  Practitioners to develop the solution;

• Apply lessons learned from past Projects to new solutions and remain
  flexible enough to change directions if initial attempt s are fruitless.
                       TEAM LEADERSHIP
CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANMAGER

MANAGERIAL IDENTITY

• A good Project Manager take full charge of the Project;
• Have the Confidence to assume Project Control (when necessary);
• Gives assurance to allow good Technical people to follow their instincts.



ACHIEVEMENTS

• To optimize Productivity of a Project Team:-

    - Manager must Reward initiative and accomplishments;
    - Demonstrate through his/her own actions that ‘’Controlled Risk taking’’
      will not be punished
         TEAM LEADERSHIP
CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANMAGER

INFLUENCE AND TEAM BUILDING

• An effective Project Manager must be able to ’‘Read People’’, be able to
  understand verbal and non-verbal symbols and react to the needs of the
  people sending these signals

• Must remain in control in high stress situation.

.
              THE SOFTWARE TEAM
The Best Project Team Structure depends on:

   •    The Management style of the organization;
   •    The number of people, who will populate the team, and their
        skill levels
   •    The overall problem difficulties.


MANTEI describes Seven Project Factors that should be considered
when Planning the structure of Software Engineering Teams.

   1.   The difficulty of the ‘Problem” to be solved
   2.   The ‘’Size’’ of the resultant programs in terms of Line Code (LOC) or
        Function Points (FP)
   3.   The “Time” that the Team will stay together (Team Lifetime)
   4.   The degree to which the problem can be modularised.
   5.   The required Quality and Reliability of the System to be built
   6.   The rigidity of the Delivery Date
   7.   The degree of Sociability (Communication) required for the Project.
                     THE SOFTWARE PROJECT TEAM TYPES
The word “Team” is fairly loosely used in Business world , calling any group of
people assigned to work together. But many of these groups just do not seem like
Teams. They do not have a common definition of success or ant identifiable “Team
Spirit”. What is missing is the phenomenon that is called “Jell”

HIGH PERFORMANCE TEAM

To achieve a high performance Project Team:-

     •   Team members must have trust in one another;
     •   The distribution of skills must be appropriate to the problem;
     •   Mavericks may have to be excluded from the team, if team cohesiveness is to be
         maintained.

JELLED TEAM

•   A Jelled Team is a group of people so strongly knit together that the whole is
    greater than the sum of the parts…

     – Once a team begins to jell, the probability of success goes way up. The team
       can become unstoppable. A juggernaut for success… Team members do not
       need to be managed in traditional way, and do not need to be motivated. They
       have got momentum.

•   Jelled Teams are significantly more productive and more motivated than average.
    They share a common Goals, a common Culture, and in many cases a ‘’Sense of
    eliteness’’ that make them unique.
           THE SOFTWARE PROJECT TEAM
For one reason or another not all Project Teams Jell. Many teams suffer
from what is called “Team Toxicity”.



FIVE FACTORS THAT FOSTERS A POTENTIALLY TOXIC TEAM ENVIRONMENT


    1.   A Frenzied work atmosphere
    2.   High frustration that causes friction among team members
    3.   A ‘’fragmented or poorly coordinated’’ Software Process
    4.   An unclear definition of roles on the Software team
    5.   Continuous and repeated exposure to failure.
              THE SOFTWARE TEAM
TEAM ANTITOXINS

•   To avoid A Frenzied work environment, the Project Manager should be certain that
    the Team has access to all Information required to do the job:

         - The major Goals and objectives once defined should not be
            changed unless absolutely necessary.

          - Bad news should not be kept secret but rather delivered to
            the team as early as possible.

•   Software People often feel Frustration when there is a lack of Authority to control
    their situation.

     •    Frustration (and Stress) can be avoided if Software team is given as much
          Responsibilities for Decision Making as possible.

     •    An inappropriately chosen Process (e.g. unnecessary or burden some work
          task or poorly chosen Work Product) can be avoided in two ways:

            a) By understanding the Product to be built and the People doing the work.

            b) By allowing the Project Team to select the Process Model
           THE SOFTWARE TEAM
TEAM ANTITOXINS (continued)

• Software Project Manager should clearly refine Roles and
  Responsibilities of Team members before the Project begins.

  - The Team itself should establish its own accountability and
    define a series of corrective approaches when a member of
    the team fails to perform.

• Every Software team experiences small failure. The key to avoid an
  atmosphere of failure is to establish team-based techniques for
  Feedback and Problem solving

  Failure of a team must be viewed as a failure by the Team itself.
  This leads to a Team-oriented approach to corrective action rather
  than the finger pointing and mistrust that grows on Toxic Team.
                    THE SOFTWARE TEAM
AGILE TEAMS
Agile Software Engineering combines a philosophy and a set of Development
Guidelines.

• The Philosophy encourages customer satisfaction with and early Incremental
  delivery of Software by Small and highly motivated Project Teams.

• The Small, highly motivated Project team also called Agile Team , adopts
  many characteristics of successful Project Teams and avoids many of the
  toxins that create problems.


    •   Agile Team are Self-organized. A Self- Organizing team does not necessarily
        maintain a single team structure but instead uses elements of random, open and
        synchronous paradigms.

    •   Agile Team members competency coupled with Group Collaboration are
        considered to be the Critical Success Factor for the team
                   THE SOFTWARE TEAM
AGILE TEAMS (Continued)

Agile Process models give the Agile Teams autonomy to make Project
Management and Technical decisions required to get the job done.

    – Planning is kept to a minimum

    – Team is allowed to select its own approach (within the constraints of
      business requirements and the organizational standards)

• As the Project proceeds, the Agile Team self organizes to focus individual
 competency in a way that is most beneficial to the project at a given
 point in time.

• To accomplish this:

    – An Agile Team might conduct brief Daily Team meetings to coordinate and
      synchronize the work that must be accomplished for the day.

• Based on information obtained from the daily meetings, the team adapts its
  approach in a way that accomplishes an incremental of work.
• As each day passes, Continual Self-organizing and collaboration move the
  team towards a completed Software Increment.
          HUMAN TRAITS OF SOFTWARE TEAM
A Software Team often struggles with the differing ‘’HUMAN TRAITS’’ of its
Team members :-

    •   Some Team members are extroverts; others are introverted

    •   Some people gather information intuitively, distilling broad concepts from
        disparate facts. Others process information linearly, collecting and
        organizing minute details from the data provided.

    •   Some members are comfortable making decisions only when a logical,
        orderly argument is presented. Others are intuitive, willing to make a
        decision based on ‘’Feel’’.

    •   Some want a detailed Project Schedule populated by organized tasks that
        enable them to achieve closure for some elements of a Project. Others prefer
        a more spontaneous environment in which open issues are okay.

    •   Some work hard to get things done well before the milestone date, thereby
        avoiding stress as data approaches, while others are energized by the rush
        to meet a last minute deadline.

It is important t o note that recognizing Human Traits is the first step
towards a building a creative Project Teams that Jell.
                 SOFTWARE PRODUCT
A Software Project Manager is confronted with a dilemma at the very
beginning of a Software Engineering Project for the following reasons:

    • Quantitaitive Project Estimates and an Organized Plan are required
      but the Information (solid information) is not available as yet.

    • Project Requirements may be fluid, changing regularly as the project
      proceeds.

          Yet a plan is needed “immediately”. !

A detailed analysis will provide all the solid information for Quantitaitive
Estimates and Project Plan . But Analysis often takes weeks or months to
complete

The ‘’Scope’’ of the Product must be established and bounded at the very
beginning of the Project.
                            SOFTWARE SCOPE
The first activity of Software Manager is to determine the Scope of Software.

Software Scope is defined in collaboration with the User Management by
asking the following Questions on the following areas:-

      - Software Context,
      - Information Objectives
      - Function and Performance of Software

•   Software Context – How does the Software to be built fit into a larger System, Products
                       or Business Context, and what Constraints are imposed as a result
                       of the Context?
•   Information Objectives – What Customer – visible Data Objectives are produced as Output
                             from the Software? What data objectives are required for Input?
•   Function and Performance – What Functions does the Software Perform to transform
                                  Characteristics to be addressed?

Software Poject Scope must be Unambigious and understandable at the Management
and Technical level’’.

A Statement of Software Scope must be bounded. (i.e. Quantitative data must be stated explicitly)

Constraint and / or Limitations are noted and mitigating factors (e.g. desired algorithms
   are well understood and available in C++) are described .
                          SOFTWARE SCOPE
PROBLEM DECOMPOSITION

During the Project Scoping no attempt is made to Decompose the Problem.
Rather decomposition is applied in two major areas :-

 –The Functionality that must be delivered
 –The Process that will be used to deliver it

 Human beings tend to apply a Divide –and- conquer strategy when they
 are confronted with a complex problem. A Complex Problem is partitioned
 into smaller problems that are more manageable.

 We apply the ‘’Divide and Conquer strategy’’ to partition a Product into
 Smaller pieces so that can be managed better, as Project Planning begins.

 Software Functions described in the Scope, are evaluated and refined to provide more
 detail prior to the beginning of Estimation. Since both Cost and Schedules are
 Functionally oriented, some degree of Decomposition is often useful.

 As the Statements of Scope evolves, a first level of Partitioning naturally occurs.
             SELECTING PROCESS MODEL


The Project Manager must decide which Process Model is most
appropriate for :

       – The Characteristics of Product itself
       – The Customers and thePpeople who will do the work (users)
       – The Project Environment in which the Software works

• After Selection of a Process Model , the Software Team then defines
  a Preliminary Project Plan based on the set of ‘’Common Process
  Framework’’ (CPF) Activities.

• Once the Preliminary Project Plan is established, Process
  Decomposition begins.

A Complete Project Plan, reflecting the Work Tasks required to
populate the Framework Activities can be created .
MELDING THE PRODUCT AND PROCESS
• Project Planning begins with the melding of Product and the Process.

• Each Product Function to be engineered by the Software Team must
  pass through the ‘’Set of Framework Activities’’ that has been defined
  for a Software organization.
Assuming that an Organization has adapted the following ‘’Set of Common
 Process Framework Activities’’.
          •   Communication
          •   Planning
          •   Modeling
          •   Construction
          •   Deployment

• Set of the Common Process Framework Activates are listed in the top row of
  a matrix and the Software Engineering Work Tasks entered in the following
  rows.

• The team members who work on the Product Function will apply each of the
   Framework activities to it.
         MELDING THE PRODUCT AND PROCESS
• The job of the Project Manager is to Estimate Resource requirements Start
 Dates and End Dates for the tasks associated with each cell, and work
 Products to be produced as a consequence of each task.




                                                COMMUNICATION




                                                                                      CONSTRUCTION
                                                                                                     DEPLOYMENT
                                                                           MODELING
                                                                PLANNING
   COMMON PROCESS
   FRAMEWORK ACTIVITIES

   SOFTWARE ENGINEERING TASKS
   Product Functions
     Text Input
     Editing and Formating
     Automatic Copy Edit
     …………………………...
     ………………………..
     ………………………….
      File Management
      Document Production
MELDING THE PRODUCT AND PROCESS
• The Process Framework is invariant and serves as the basis for all Software
  work performed by Software organization.

• The Actual Software Engineering Tasks (i.e. Work Task) do actually vary.

• Work Tasks must be adapted to the specific needs of the Project.


• Process decomposition commences when the project manager asks,

       ’’How do we accomplish this Framework Activity’’?

For example: A small relatively simple Project might require the following ‘’Work
            Tasks’’ for the ‘’Communication Activity’’:

                  1. Develop list of clarification issues
                  2. Meet with Customer to address clarification issues
                  3. Jointly develop a statement of Scope
                  4. Review the Scope with all concerned
                  5. Modify the Statement of Scope as required
                          THE PROJECT
In order to manage a Successful Software Project, we must understand
What can go wrong so that the problem can be avoided,

John Reel defines 10 Signs that indicate an Information Systems Project
is in Jeopardy:-


   1.  Software People don’t understand their Customers’
       needs
   2. The Product Scope is poorly defined
   3. Changes are managed poorly
   4. The chosen Technology changed
   5. Business needs change or ill defined
   6. Project Deadlines are unrealistic
   7. Users are resistant
   8. Sponsorship is lost (or never obtained)
   9. The Project Team lacks People with appropriate skills
   10. Managers / Practitioners avoid best practice and Lessons
       learned.
        AVOIDING PROBLEMS SIGNED BY JEOPARDY
Jaded Industrial Professionals often refer (half facetiously) to the
90 – 90 Rule when discussing particularly difficult Software
Projects.

The seeds that lead to the 90 – 90 rule are contained in the 10 Project
Jeopardy Signs.


90 – 90 RULE

    –   The first 90 % of a System absorbs 90 % of the Allocated Effort and Time.

    –   The last 10 % takes the other 90 % of the Allocared Effort and Time.


John Reel Suggests a Five-part Common-sense approach to avoid Project
Problems:-

            1.   Start with right foot
            2.   Maintain Momentum
            3.   Track Progress
            4.   Make Smart Decision
            5.   Conduct a Post-mortems Analysis
         AVOIDING PROBLEMS SIGNED BY JEOPARDY
1. START WITH RIGHT FOOT

•     This is accomplished by working hard to understand the problem that
      is to be solved and then setting realistic objectives and expectations
      for everyone who will be invloved in the Project.
•     This is achieved by building the ‘’Right Team’’ and giving the Team
      the autonomy, authority and technology needed for job
2. MAINTAIN MOMENTUM :

    Many Project get off a good start and then slowly disintegrate. To maintain
    momentum:-
        The Project Team should emphasize quality in every task it performs.
        The Project Manager must provide initiatives to keep ‘’Staff turnover’’ to an
         absolute minimum.
        Senior Management should do everything posssible to ‘’Stay out of the
         Project Team’s way’’.
         •    (Management should reduce bureaucracy to a minimum, Eleminate
              exraneaos meetings and eliminate dogmatic adherence to Project rules.
              The Project team should be self-organizing and autonomous.
       AVOIDING PROBLEMS SIGNED BY JEOPARDY
3. TRACK PROGRESS

•      Progress is tracked as Work products (i.e Specification, Source code, Test
       results etc) are produced and approved (using Formal technical reviews),
       as part of a Quality Assurance activity.

•      Additionally, Software Process and Project Measures can be collected and
       used to ‘’Assess Progress Against Averages’’ developed for the Software
       Development Organizations.

4. MAKE SMART DECISION

    In essence, the decisions of Project Manager and the Software Team should be
    ‘’keep ıt sımple”. Whenever possible decide to:-

          •   Use , commercial ‘Off- the -shelf Software’’ or Existing Software components.
          •   Avoid Custom Interface when standard approaches are available.
          •   Identify and then avoid obvious risks,
          •   Allocate more time than you think is needed to complex or risky tasks.
         AVOIDING PROBLEMS SIGNED BY JEOPARDY
5. CONDUCT A POSTMORTEN ANALYSIS

•   Establish a Consistent mechanism for extracting lessons learned for
    each Project.
•   Evaluate Planned and Actual Schedules
•   Collect and Analyze Software Project Metrics
•   Record findings in written form
             THE W5HH PRINCIPLE
BOEHM suggest an organizing Principle that scale down to
provide simple Project Plans for simple Projects.

Boehm suggests an Approach that addresses the following areas:

      •   Project Objectives
      •   Milestones and Schedules
      •   Responsibilities
      •   Management and Technical approaches
      •   Required Resources
                      THE W5HH PRINCIPLE
W5HH (WWWWWHH) Principle is based on a series of questions that
leads to a definition of key Project Characteristics and the resulting
Project Plan.


•    Why is the System being Developed?
•    What will be done?
•    When will it be done?
•    Who is responsible for a function?
•    Where are they organizationally located?
•    How will the job be done technically and Managerially?
•    How much of each resource is needed?
                                THE W5HH PRINCIPLE
Why is the System being Developed?
 The answer to this question enables all parties to asses the validity of business reasons for the
 Software work. (To justify the expenditure of People, Time, and Money for the Business purpose)

What will be done?
  The answer establishes the task set that will be required for the project

When will it be done?
 The answer helps the Project Team to establish a Project Schedule by identifying when Project Tasks
 are to be conducted and when Milestones are to be reached.

Who is responsible for a function?
 The answer helps to define the roles and responsibilities of each member within the Project team.

Where are they organizationally located?
 Not all roles and responsibilities reside within the Project team itself. Users, Customers and other
 stakeholders may have responsibilities as well.

How will the job be done technically and Managerially?
 Once Product Scope is established a Management and Technical strategy for Project must
 be defined.

How much of each resource is needed?
 The answer is derived by developing estimates based on answers of the above questions
                        CRITICAL PRACTICES
A team of Software Engineering experts has developed a list of ‘’Critical
Software Practices for Performance-based Management;

These practices are consistently used by , and considered critical by , highly
successful Software Projects and Organizations whose ‘bottom line’
performance is consistently much better than industry averages.


Critical Practices include the followings

                Metric-based Project Management
                Empirical Costs and Schedule Estimation
                Earned Value Tracking
                Formal Risk Management
                Defect Tracking Against Quality Targets
                People Aware Management

The Critical Practices is also known as QUICK LOOK QUESTIONS.
                    SUMMARY
•   The Project Management activity encompasses Measurements
    and Metrics, Estimation and Scheduling, Risk Analysis,
    Tracking, and Project Control .

•   The pivot element in all Software Projects is ‘’PEOPLE’’.

•   Software Engineers can be organized in a number of different
    Team structures that ranges from Traditional control hierarchies
    to ‘’Open Paradigm’’ Project Teams.

•   A variety of coordination and communication techniques can be
    applied to support the work of the Project Team. In general,
    Formal reviews and Informal person-to-person communication
    have the most value for Software Practitioners.

•   Each of the Project Management Activity is considered in the
    chapters that follow.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:56
posted:5/17/2012
language:English
pages:40