Management of Large Software Projects - PowerPoint PPT Presentation

Loading...

PPT – Management of Large Software Projects PowerPoint presentation | free to download - id: 5995ad-ZGY4M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Management of Large Software Projects

Description:

Management of Large Software Projects Tathagat Varma MindTEK, 25-Mar-2004 Disclaimer Most of what I quote is from standard textbooks & research firms A little of what ... – PowerPoint PPT presentation

Number of Views:3214
Avg rating:3.0/5.0
Slides: 67
Provided by: Tath
Learn more at: http://managewell.net
Category:

less

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

Title: Management of Large Software Projects


1
Management of Large Software Projects
  • Tathagat Varma
  • MindTEK, 25-Mar-2004

2
Disclaimer
  • Most of what I quote is from standard textbooks
    research firms
  • A little of what I say is from my own limited
    experience. I am still learning Software Project
    Management !
  • I am not specifically advocating any specific
    process or methodology
  • Some principles can also be applied in smaller
    projects
  • Apply your judgment as per your own requirements
    and situation

3
Topics not covered
  • Project Management
  • Project Structure, Organization of roles and
    responsibilities
  • Long-distance Project Management ?
  • People Management
  • Performance Management
  • Managing Cross-cultural teams
  • Quality Management
  • Detailed discussion on Software Management
    Processes and Software Engineering Processes
  • Using Measurement and Metrics for Project
    Management
  • Technology Management
  • Configuration Management

4
Agenda
  • Economics, Success Rates and Effort for Large
    Software Projects
  • Reduce Software Size
  • Managing Late Changes
  • Staffing and Recruitment
  • Productivity
  • Misc. Topics
  • My Experiences
  • QA

5
Reality Check 1
6
Reality check 2
7
Project Outcome
  • Standish categorizes projects into three
    resolution types
  • Successful The project is completed on time and
    on budget, with all features and functions
    originally specified.
  • Challenged The project is completed and
    operational, but overbudget, late, and with fewer
    features and functions than initially specified.
  • Failed The project is canceled before
    completion, or never implemented.

8
Are we improving ?
9
Reasons behind this improvement
  • Standish Chairman Jim Johnson says, The primary
    reason is the projects have gotten a lot smaller.
    Doing projects with iterative processing as
    opposed to the waterfall method, which called for
    all project requirements to be defined up front,
    is a major step forward.
  • People have become much more savvy in project
    management, Johnson says. When we first started
    the research, project management was a sort of
    black art.

10
Reasons
  • The Standish Group predicts that most projects
    started and resolved this year (2001) will be
    microprojects ones lasting no more than four
    months and run by four people. CHAOS research
    shows minimization as a key factor in successful
    projects. The microproject is the ultimate in
    minimization. Many last only three to four weeks.
    Don't confuse microprojects with
    milestonesmicroprojects live and die on usable
    deliverables.

11
So, what is a successful software project ?
  • Booch A successful software project is one
    whose deliverables satisfy and possibly exceed
    the user's expectations, was developed in a
    timely and economical fashion, and is resilient
    to change and adaptation

12
What makes a project successful ?
  • Recipe for Success CHAOS Ten
  • Executive Support 18
  • User Involvement 16
  • Experienced Project Manager 14
  • Clear Business Objectives 12
  • Minimized Scope 10
  • Standard Software Infrastructure 8
  • Firm Basic Requirements 6
  • Formal Methodology 6
  • Reliable Estimates 5
  • Other criteria 5
  • The Chaos Report (2000) argues that 97 of
    successful projects have an experienced project
    manager at the helm.

13
Project Sizes
  • Size as team strength could be
  • Trivial Size 1 person
  • Small Size 5 people
  • Moderate Size 25 people
  • Large Size 125 people
  • Huge Size 625 people
  • The more the size, the greater are the costs of
    management overhead, communication,
    synchronizations among various projects or
    modules, etc.

14
Why large projects ?
  • Software and System complexity has gone up
    manifold in last 10-15 years when two software
    engineers could make a software over a weekend
    in their garage also, there were no customer /
    marketing pressures to deliver fast
  • Now, complex systems needs a huge amount of
    software delivered very fast
  • If schedule is not a constraint, projects could
    still be delivered by a relatively smaller team

15
Economies of Large Projects
  • Contrary to most manufacturing processes, the
    more software you build, the more expensive it
    is.
  • For example, for a given application, a 10 KLOC
    software solution will cost less per line than a
    100 KLOC software solution. How much less ?
    Assume that a 100 KLOC system requires 900
    staff-months for development, or about 1.37 hrs /
    LOC. If the same system were only 10 KLOC and all
    other parameters were held constant, this project
    would be estimated at 62 staff-months, or about
    0.87 hour / LOC.

16
Economics
  • So, it is better to reduce the size of a project
    as much as possible.
  • Project Size could be reduced by
  • Reducing software size
  • Reducing project team size

17
Success by Project Size
18
Characteristics of Large Projects
  • Substantial management overhead need dedicated
    project manager and sub-project managers
  • Need lot of planning and effort to synchronize
    project-level and sub-project level workflows and
    balance resources among various teams
  • Needs very good processes to manage the workflow
    and quality because there are many average
    people in a large team the probability of
    recruiting, maintaining and retaining a large
    number of exceptional people is small !

19
Planning Large Projects
  • Finalize the Architecture first, and manage it
    continuously
  • Plan multiple iterations, if possible
  • Identify dedicated roles to manage projects
    technical and management progress and control
  • Automate the CM, change and defect tracking
    environment
  • Reduce Project Size

20
Managing Software Architecture
  • Software Architecture becomes extremely important
    for a large product / project
  • Ideally, a full-time dedicated Software Architect
    must be allocated to a large project in the
    initial stages of the project
  • Architecture becomes the Bible of the
    development team whatever they do (or do not do
    !) is influenced by it. It helps enforce a common
    design style in all modules. It also helps
    prevent common errors that might otherwise happen
    if all modules do their design independently !

21
Project Size Vs. Effort
22
Reduce Software Size
  • The less software we write, the better it is for
    project management and for product quality
  • The cost of software is not just in the cost of
    coding alone it is also in
  • Analysis of requirements
  • Design
  • Review of requirements, design and code
  • Test Planning and preparation
  • Testing
  • Bug fix
  • Regression testing

23
Reduce
  • Coding takes around 15 of development cost
  • Clearly, if we reduce 15 hrs of coding, we can
    directly reduce 100 hrs of development effort,
    and also reduce the project team size
    appropriately !

24
Reduce
  • Size reduction is defined in terms of
    human-generated source code. Most often, this
    might still mean that the computer-generated
    executable code is at least the same or even more
  • Software Size could be reduced by
  • Software Re-use
  • Use of COTS
  • Programming Languages

25
Software Re-use
  • Common architectures, common processes, precedent
    experience, and common environment are all
    instances of re-use
  • Black-box re-use refers to component re-use
    without any internal modification
  • While-box re-use refers to re-use where some
    internal changes are necessary before the
    component could be incorporated
  • Components get re-used for economic benefits.
    However, the cost of building a component for
    re-use could be higher compared to just building
    it for its intended usage

26
Use of COTS
  • COTS (Commercial Off-The Shelf Software) are
    increasingly available to shorten the product
    development lead time.
  • Advantages available much early in the
    lifecycle, most often good technical support,
    predictable license cost, mature technology, test
    software
  • Disadvantages frequent upgrades, dependency on
    (single) vendor, some generalizations might not
    be very efficient, no control over upgrades and
    maintenance, extra features that are unnecessary
    can consume extra resources, etc.

27
Programming Languages
  • The high-level languages are more expressive
    than the low-level languages they can express
    the same things with less number of instructions
  • Typically, what you achieve in C could be
    achieved with just around 50 SLOC in C, and
    around 25 SLOC of VB. Plus, there could be
    additional savings in the effort for review,
    rework, etc.
  • However, not all languages are suitable for all
    kind of domains. Also, this freedom of language
    might not always be available

28
Managing Late Changes to Requirements
29
Managing Late Changes
  • Robs Rule of Large Projects For Large Projects,
    there is no such thing as a small change.
  • Say NO when you have to !
  • Ideally, the Project Manager should be the
    gatekeeper of the Change Management process

30
Staffing Large Teams
  • It is impossible to staff a non-trivial project
    with personnel who all have optimal experience,
    are fully trained in the tools and technologies,
    and possess IQs greater than 130. (page 43, ref
    1)
  • Teamwork is much more important than the sum of
    the individuals. With software teams, a project
    manager needs to configure a balance of solid
    talent with highly skilled people in the leverage
    positions. (page 43, ref 1)

31
Staffing
  • Staffing principles from Barry Boehm
  • The principle of top talent use better and fewer
    people
  • The principle of job matching fit the tasks to
    the skills and motivation of the people available
  • The principle of career progression an
    organization does best in the long run by helping
    its people to self-actualize
  • The principle of team balance select people who
    will complement and harmonize with one another
  • The principle of phase-out keeping a misfit on
    the team doesnt benefit anyone

32
Staffing
  • In general, staffing is achieved by these common
    methods
  • If people are already available with required
    skill set, just take them
  • If people are already available but do not have
    the required skills, re-train them
  • If people are not available, recruit trained
    people
  • If you are not able to recruit skilled people,
    recruit and train people

33
Staffing
  • Staffing of key personnel is very important
  • Project Manager
  • Software Architect

34
Project Manager
  • Hiring Skills Be able to get the right person
    for the right job
  • Customer-interface Skills Avoiding adversarial
    relationships among stakeholders is a
    pre-requisite for success
  • Decision-making skill Hard to define, this is
    the most important difference between an average
    manager and a good manager

35
Project Manager
  • Team-building skill Teamwork requires that a
    manager establish trust, motivate progress,
    exploit eccentric prima donnas, transition
    average people into top performers, eliminate
    misfits, and consolidate diverse opinions into a
    team direction
  • Selling Skill Must be able to sell all
    stakeholder of a project for the ultimate success
    of his project

36
Software Architect
  • Technical Skills the most important skills for
    an architect. These must include skills in both,
    the problem domain and the solution domain
  • People Management Skills must ensure that all
    people understand and implement the architecture
    in exactly the way he has conceptualized it. This
    calls for a lot of people management skills and
    patience.
  • Role Model must be a role model for the software
    engineers they would emulate all good (and also
    all bad !) things that the architect does

37
Recruitment
38
Recruitment
  • Seven golden rules of recruitment
  • Recruit only if you can not get similar talent
    from within the company
  • Never hire in a hurry
  • Always hire people smarter than you
  • Hire for attitude, train for skills
  • If you have any doubt, better dont hire
  • Hire people who dare to disagree with you
  • Hire freshers from the college (15

39
Recruitment
  • Nowadays, hiring a mutual process even the
    candidate selects the company he wants to work
    with so make sure that the interview process is
    not like an examination
  • Look for the following while hiring
  • Merit means the past performance
  • Potential means the capability to achieve
    results in the future
  • Ambition what does the person what to achieve
    in career
  • For junior people, merit is more important, while
    for senior people, potential is more important
    (on a relative scale)
  • Watch out for fake / clichéd ambition, but never
    hire someone with low ambition

40
Recruitment
  • While hiring, try to hire senior people first
    senior people are required for building the team,
    and junior people can always be in-sourced /
    staffed during the later phases
  • While hiring, always hire the people who are
    star performers in their current organizations
    it would inspire other good people to join you

41
Training Mentoring
  • Not all the people who join your team might be
    experts, or even have above-average knowledge of
    your projects technology most of them would
    need some training or other
  • Plan for the training upfront
  • Mentoring ensures a good hand-holding for
    newcomers to a team and culture-building in the
    team

42
Role Identification
  • The role must be identified depending on these
    two factors
  • Individuals capability and interest must be kept
    in mind as much as possible
  • Interest of the Project / Organization is always
    superior to the individuals interest and
    capability in case of a conflict, the larger
    interest must be honored

43
Task Allocation
  • Ideally, each person must be able to choose his /
    her task this would motivate him / her to give
    best performance
  • But, this might not be possible always due to
  • Some team members joining the project late have
    less choice
  • Some team members asking for allocation of task
    but they are not competent to perform it
  • Some task is already identified for a more
    competent person who is yet to join

44
Task
  • If the ideal task allocation is not possible, the
    PM should try to find the next best option /
    choice and allocate.
  • If no option is available and the team member
    does not want to accept an alternate even in the
    interest of the project / organization, it is
    better not to take such person in the team
    because he might never be a motivated team member.

45
Managing Cross-cultural Teams
  • Big subject many books have been written about
    this
  • In todays context, the person who can manage in
    different cultural work styles is needed. It is
    not important if you personally subscribe to that
    way of working or not !
  • Some personal experiences
  • European meticulous, think of long-term plan /
    impact, very high productivity but not keen to
    overtime, high focus on quality of life and
    family
  • Chinese go-getter attitude, emphasis is on hard
    work (rather than on smart work),
    consensus-oriented management,

46
Cross-cultural...
  • To me, the three most important things are
  • Ensure that there is no difference between the
    expectations and evaluation criteria of tasks
    between the people of different cultures just
    because of the culture difference alone
  • Focus on strengths of different cultures / people
    not on its weaknesses
  • Treat everyone the same

47
Reducing Team Size
  • Assuming that we have already reduced the
    software size as much as possible, the primary
    techniques for reducing the team size are
  • Outsourcing
  • In-sourcing
  • Improving Productivity
  • Increasing the project schedule
  • Making multiple releases

48
Outsourcing
  • Outsourcing could be an effective way to quickly
    build a large team, and / or manage peaks and
    valleys in the project lifecycle
  • Personally, I think we should plan to outsource
    15 - 20 of work to de-risk the project
  • Make sure you are not putting all your eggs in a
    single basket !

49
In-sourcing
  • In-sourcing helps get the people only in the
    phase when you require, and then reduce them when
    you have less workload.
  • I have worked with in-sourced team members with
    mixed results. The success rates were almost
    always 50
  • Dont put too many of in-sourced people in a
    single team

50
Productivity Metrics ?
51
Productivity vs. Size
52
Improving Productivity
  • Systemic / Process
  • Direct get it right the first time
  • Do proper estimation, planning and scheduling
  • Identify the right processes for the workflow
  • Identify the right set of tools for the project
  • Orient the team members in the usage of processes
    and tools
  • Indirect reduce the scrap and rework
  • Allocate effort for rework effort
  • Monitor and control the rework effort
  • Ensure the reviews (at least the initial reviews)
    are very rigorous this way, you might get more
    rework in the early phases but you can perhaps
    reduce more rework in the later stages

53
Improving Productivity
  • Motivation
  • Task allocation as per peoples interest (might
    not be always possible) and capability
  • Make sure there are adequate amount of offs and
    breaks team building activities, formal and
    informal gatherings, team dinners, etc.
  • Progress tracking must be task-based rather
    than time-based

54
Improving Productivity
  • Environmental
  • Peaceful, no-disturbance work area
  • No external interruptions for meetings, etc.
  • All technical resources available readily to the
    team (Internet, library, manuals, etc.)
  • Office errand boy for Xerox, fax, etc.
  • Pantry, canteen available within walking distance
  • If need be, provide concierge service to
    employees in office itself

55
Increasing the Project Schedule
  • Customer might or might not always agree for
    this, but it might be possible that the
    Customer would tolerate 90 of the functionality
    delivered late if they could have 10 of it on
    time (page 59, ref 1)
  • At times, increasing the schedule might be a
    better way to improve the chances of success of a
    project rather than to address it with hard work
    or with more manpower

56
Making Multiple Releases
  • When we make multiple releases, we might mitigate
    the risk of a late design breakage we could
    also use it to increase the project schedule
    thereby reducing the team size substantially
    without seriously impacting the product quality
  • The key is to identify the peripheral
    requirements that are probably not so important
    or nice to have features and deliver them in
    the next release. For the first release, focus on
    the core / key requirements

57
Software Process
  • It is a myth that one single software process can
    be defined and deployed for every kind / type /
    size of software project
  • Large projects needs large or heavy processes
    small project need small or lightweight
    processes
  • Good planning involves good process planning, and
    selecting the right weight of the processes for
    the tasks

58
Process...
  • For example, in US Defense projects, the cost of
    a project might be up to 3 times the cost of a
    comparable commercial project - but the business
    needs might justify such costs (mission-control
    systems, etc.)
  • One important thing while defining the process
    Use your judgement to interpret the process
    correctly for your needs. Dont assume that
    everything in the process is always right !

59
Process
  • Too much medicine can kill the patient !!!

60
My Experiences 2001
  • We were building a Gigabit Switch Router (GSR)
  • Code estimate 600 KLOC
  • Code actual 700 KLOC
  • Manpower estimate 110 (Dev) 15 (QA)
  • Subcontracted around 50 KLOC
  • PDT Kick-off to SRS 3 months
  • SRS-MST 6 months (late by 2 months !)
  • Integration 10 months !!!

61
My Experiences 2002
  • We were building a Softswitch with 3G Wireless
    access capabilities kind of wireless wireline
    softswitch
  • First Code Estimate 300 KLOC
  • Second Code Estimate gt500 KLOC
  • Final Code (actual) 570 KLOC
  • Team 145 (Dev) and 45 (QA)
  • PDT Kick-off to SRS 2 months
  • SRS-MST 3 months (wireline) to 6 months
    (wireless)
  • Integration 2-3 months
  • Field Trials within 2 months of completing Dev
  • Commercial Orders within 2 months of completing
    field trials
  • MST-TR4A 7 months

62
My Experiences 2003
  • We were building Routing Platform with complete
    IPv6 support, routing protocols (RIP, ISIS, BGP,
    OSPF, etc.) and complete MPLS support
  • First Code Estimate 300 KLOC
  • Second Code Estimate 550 KLOC
  • Final Code (actual) 600 KLOC
  • Manpower 120 (Dev) and 17 (QA)
  • PDT Kick-off to SRS 3 months
  • SRS-MST 6 months (delayed by only 15 days !)
  • Integration 1 month (90 complete).
  • MST-TR4A 4.5 months

63
Conclusions
  • Being part of a large project is a blessing. I
    call it as the finishing school for software
    managers !
  • I rate my own success rates as 50 (in 2001) to
    80 (in 2003). You grow with every experience.
  • I did not cover many other important ingredients
    like communication, tracking, cross-team
    technical reviews, etc.

64
Further References
  • Software Project Management A Unified
    Framework by Walker Royce
  • http//www.computer.org/software/so1996/s4024abs.h
    tm
  • Managing Software Engineers -
    http//www.arsdigita.com/asj/managing-software-eng
    ineers/
  • http//ieeexplore.ieee.org/xpl/abs_free.jsp?arNumb
    er366170
  • http//www.itweb.co.za/sections/techforum/2004/040
    3160836.asp
  • www.columbia.edu/jm2217/Q7503_12post.ppt
  • http//www.gantthead.com/article.cfm?ID208820
  • http//www.processimpact.com/articles/proj_mgmt_ti
    ps.html
  • http//www-106.ibm.com/developerworks/websphere/li
    brary/techarticles/0306_perks/perks.html

65
Questions
66
Thank You
About PowerShow.com