Management of Large Software Management of Large Software ProjectsProjects

Tathagat VarmaTathagat VarmaMindTEK, 25-Mar-2004MindTEK, 25-Mar-2004

DisclaimerDisclaimer Most of what I quote is from standard textbooks Most of what I quote is from standard textbooks

& research firms& research firms A little of what I say is from my own limited A little of what I say is from my own limited

experience. I am still learning Software Project experience. I am still learning Software Project Management !Management !

I am not I am not specificallyspecifically advocating any specific advocating any specific process or methodologyprocess or methodology

Some principles can also be applied in smaller Some principles can also be applied in smaller projectsprojects

Apply your judgment as per your own Apply your judgment as per your own requirements and situationrequirements and situation

Topics not coveredTopics not covered

Project ManagementProject Management Project Structure, Organization of roles and responsibilitiesProject Structure, Organization of roles and responsibilities Long-distance Project Management Long-distance Project Management

People ManagementPeople Management Performance Management Performance Management Managing Cross-cultural teamsManaging Cross-cultural teams

Quality ManagementQuality Management Detailed discussion on Software Management Processes Detailed discussion on Software Management Processes

and Software Engineering Processesand Software Engineering Processes Using Measurement and Metrics for Project ManagementUsing Measurement and Metrics for Project Management

Technology ManagementTechnology Management Configuration ManagementConfiguration Management

AgendaAgenda

Economics, Success Rates and Effort for Economics, Success Rates and Effort for Large Software ProjectsLarge Software Projects

Reduce Software SizeReduce Software Size Managing Late ChangesManaging Late Changes Staffing and RecruitmentStaffing and Recruitment ProductivityProductivity Misc. TopicsMisc. Topics My ExperiencesMy Experiences Q&AQ&A

Reality Check #1Reality Check #1

Reality check #2Reality check #2

Project OutcomeProject Outcome

Standish categorizes projects into three Standish categorizes projects into three resolution types:resolution types: Successful:Successful: The project is completed on time The project is completed on time

and on budget, with all features and functions and on budget, with all features and functions originally specified.originally specified.

Challenged:Challenged: The project is completed and The project is completed and operational, but overbudget, late, and with operational, but overbudget, late, and with fewer features and functions than initially fewer features and functions than initially specified.specified.

Failed:Failed: The project is canceled before The project is canceled before completion, or never implemented.completion, or never implemented.

Are we improving ?Are we improving ?

Reasons behind this improvementReasons behind this improvement

Standish Chairman Jim Johnson says, “The Standish Chairman Jim Johnson says, “The primary reason is the primary reason is the projects have gotten a lot projects have gotten a lot smallersmaller. Doing projects with iterative processing . Doing projects with iterative processing as opposed to the waterfall method, which called as opposed to the waterfall method, which called for all project requirements to be defined up for all project requirements to be defined up front, is a major step forward.” front, is a major step forward.”

““People have become much more savvy in People have become much more savvy in project managementproject management,” Johnson says. “When we ,” Johnson says. “When we first started the research, project management first started the research, project management was a sort of black art. was a sort of black art.

Reasons…Reasons…

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

So, what is a “successful” software So, what is a “successful” software project ?project ?

Booch – “A successful software project is Booch – “A successful software project is one whose deliverables satisfy and one whose deliverables satisfy and possibly exceed the user's expectations, possibly exceed the user's expectations, was developed in a timely and economical was developed in a timely and economical fashion, and is resilient to change and fashion, and is resilient to change and adaptation”adaptation”

What makes a project “successful” ?What makes a project “successful” ?

Recipe for Success: CHAOS TenRecipe for Success: CHAOS Ten Executive Support Executive Support 18%18% User InvolvementUser Involvement 16%16% Experienced Project ManagerExperienced Project Manager 14%14% Clear Business ObjectivesClear Business Objectives 12%12% Minimized ScopeMinimized Scope 10%10% Standard Software InfrastructureStandard Software Infrastructure 8%8% Firm Basic RequirementsFirm Basic Requirements 6%6% Formal MethodologyFormal Methodology 6%6% Reliable EstimatesReliable Estimates 5%5% Other criteriaOther criteria 5%5%

The Chaos Report (2000) argues that 97% of The Chaos Report (2000) argues that 97% of successful projects have an experienced project successful projects have an experienced project manager at the helm. manager at the helm.

Project SizesProject Sizes

Size as team strength could be :Size as team strength could be : Trivial SizeTrivial Size: 1 person: 1 person Small SizeSmall Size: 5 people: 5 people Moderate SizeModerate Size: 25 people: 25 people Large SizeLarge Size: 125 people: 125 people Huge SizeHuge Size: 625 people: 625 people

The more the size, the greater are the costs The more the size, the greater are the costs of management overhead, communication, of management overhead, communication, synchronizations among various projects or synchronizations among various projects or modules, etc.modules, etc.

Why large projects ?Why large projects ?

Software and System complexity has gone up Software and System complexity has gone up manifold in last 10-15 years when two manifold in last 10-15 years when two software engineers could make a ‘software’ software engineers could make a ‘software’ over a weekend in their garage – also, there over a weekend in their garage – also, there were no customer / marketing pressures to were no customer / marketing pressures to deliver fastdeliver fast

Now, Now, complex systemscomplex systems needs a huge needs a huge amount of software amount of software delivered very fastdelivered very fast

If schedule is not a constraint, projects could If schedule is not a constraint, projects could still be delivered by a relatively smaller teamstill be delivered by a relatively smaller team

‘‘Economies’ of Large ProjectsEconomies’ of Large Projects

Contrary to most manufacturing processes, the Contrary to most manufacturing processes, the more software you build, the more expensive it is.more software you build, the more expensive it is.

For example, for a given application, a 10 KLOC For example, for a given application, a 10 KLOC software solution will cost less per line than a 100 software solution will cost less per line than a 100 KLOC software solution. How much less ? Assume KLOC software solution. How much less ? Assume that a 100 KLOC system requires 900 staff-months that a 100 KLOC system requires 900 staff-months for development, or about for development, or about 1.37 hrs / LOC1.37 hrs / LOC. If the . If the same system were only 10 KLOC and all other same system were only 10 KLOC and all other parameters were held constant, this project would parameters were held constant, this project would be estimated at 62 staff-months, or about be estimated at 62 staff-months, or about 0.87 hour 0.87 hour / LOC/ LOC..

Economics…Economics…

So, it is better to So, it is better to reduce the size of a reduce the size of a project as much as possibleproject as much as possible..

Project Size could be reduced byProject Size could be reduced by Reducing software sizeReducing software size Reducing project team sizeReducing project team size

Success by Project SizeSuccess by Project Size

Characteristics of Large ProjectsCharacteristics of Large Projects

Substantial management overheadSubstantial management overhead – need – need dedicated project manager and sub-project dedicated project manager and sub-project managersmanagers

Need Need lot of planning and effort to synchronize lot of planning and effort to synchronize project-level and sub-project level workflowsproject-level and sub-project level workflows and and balance resources among various teamsbalance resources among various teams

Needs Needs very good processes to manage the very good processes to manage the workflow and qualityworkflow and quality because there are many because there are many ‘average’ people in a large team – the probability ‘average’ people in a large team – the probability of recruiting, maintaining and retaining a large of recruiting, maintaining and retaining a large number of exceptional people is small !number of exceptional people is small !

Planning Large ProjectsPlanning Large Projects

Finalize the Architecture first, and manage Finalize the Architecture first, and manage it continuouslyit continuously

Plan multiple iterations, if possiblePlan multiple iterations, if possible Identify dedicated roles to manage Identify dedicated roles to manage

project’s technical and management project’s technical and management progress and controlprogress and control

Automate the CM, change and defect Automate the CM, change and defect tracking environmenttracking environment

Reduce Project SizeReduce Project Size

Managing Software ArchitectureManaging Software Architecture Software Architecture becomes extremely Software Architecture becomes extremely

important for a large product / projectimportant for a large product / project Ideally, a full-time dedicated Software Architect Ideally, a full-time dedicated Software Architect

must be allocated to a large project in the initial must be allocated to a large project in the initial stages of the projectstages of the project

Architecture becomes the ‘Bible’ of the Architecture becomes the ‘Bible’ of the development team – whatever they do (or do not development team – whatever they do (or do not do !) is influenced by it. It helps enforce a do !) is influenced by it. It helps enforce a common design style in all modules. It also common design style in all modules. It also helps prevent common errors that might helps prevent common errors that might otherwise happen if all modules do their design otherwise happen if all modules do their design independently !independently !

Project Size Vs. EffortProject Size Vs. Effort

Reduce Software SizeReduce Software Size

The less software we write, the better it is The less software we write, the better it is for project management and for product for project management and for product qualityquality

The cost of software is not just in the cost The cost of software is not just in the cost of ‘coding’ alone; it is also inof ‘coding’ alone; it is also in Analysis of requirementsAnalysis of requirements DesignDesign Review of requirements, design and codeReview of requirements, design and code Test Planning and preparationTest Planning and preparation TestingTesting Bug fixBug fix Regression testingRegression testing

Reduce…Reduce…

‘‘Coding’ takes around 15% of Coding’ takes around 15% of development cost development cost

Clearly, if we reduce 15 hrs of coding, we Clearly, if we reduce 15 hrs of coding, we can directly reduce 100 hrs of can directly reduce 100 hrs of development effort, and also reduce the development effort, and also reduce the project team size appropriately !project team size appropriately !

Reduce…Reduce…

Size reduction is defined in Size reduction is defined in terms of terms of human-generated source codehuman-generated source code. Most . Most often, this might still mean that the often, this might still mean that the computer-generated executable code is at computer-generated executable code is at least the same or even moreleast the same or even more

Software Size could be reduced bySoftware Size could be reduced by Software Re-useSoftware Re-use Use of COTSUse of COTS Programming LanguagesProgramming Languages

Software Re-useSoftware Re-use

Common architectures, common processes, Common architectures, common processes, precedent experience, and common environment are precedent experience, and common environment are all instances of re-useall instances of re-use

Black-box re-use refers to component re-use without Black-box re-use refers to component re-use without any internal modificationany internal modification

While-box re-use refers to re-use where some While-box re-use refers to re-use where some internal changes are necessary before the internal changes are necessary before the component could be incorporatedcomponent could be incorporated

Components get re-used for economic benefits. Components get re-used for economic benefits. However, the cost of building a component for re-use However, the cost of building a component for re-use could be higher compared to just building it for its could be higher compared to just building it for its intended usageintended usage

Use of COTSUse of COTS COTS (Commercial Off-The Shelf Software) are COTS (Commercial Off-The Shelf Software) are

increasingly available to shorten the product increasingly available to shorten the product development lead time.development lead time.

Advantages: available much early in the Advantages: available much early in the lifecycle, most often good technical support, lifecycle, most often good technical support, predictable license cost, mature technology, test predictable license cost, mature technology, test softwaresoftware

Disadvantages: frequent upgrades, dependency Disadvantages: frequent upgrades, dependency on (single) vendor, some generalizations might on (single) vendor, some generalizations might not be very efficient, no control over upgrades not be very efficient, no control over upgrades and maintenance, extra features that are and maintenance, extra features that are unnecessary can consume extra resources, etc.unnecessary can consume extra resources, etc.

Programming LanguagesProgramming Languages The high-level languages are more ‘expressive’ The high-level languages are more ‘expressive’

than the low-level languages – they can than the low-level languages – they can ‘express’ the same things with less number of ‘express’ the same things with less number of instructionsinstructions

Typically, what you achieve in C could be Typically, what you achieve in C could be achieved with just around 50% SLOC in C++, achieved with just around 50% SLOC in C++, and around 25% SLOC of VB. Plus, there could and around 25% SLOC of VB. Plus, there could be additional savings in the effort for review, be additional savings in the effort for review, rework, etc.rework, etc.

However, not all languages are suitable for all However, not all languages are suitable for all kind of domains. Also, this freedom of language kind of domains. Also, this freedom of language might not always be availablemight not always be available

Managing Late Changes to Managing Late Changes to RequirementsRequirements

Managing Late Changes…Managing Late Changes…

Rob’s Rule of Large Projects: Rob’s Rule of Large Projects: For Large For Large Projects, there is no such thing as a small Projects, there is no such thing as a small changechange..

Say ‘NO’ when you have to !Say ‘NO’ when you have to ! Ideally, the Project Manager should be the Ideally, the Project Manager should be the

gatekeeper of the Change Management gatekeeper of the Change Management processprocess

Staffing Large TeamsStaffing Large Teams

““……It is impossible to staff a non-trivial project It is impossible to staff a non-trivial project with personnel who all have optimal with personnel who all have optimal experience, are fully trained in the tools and experience, are fully trained in the tools and technologies, and possess IQs greater than technologies, and possess IQs greater than 130.130.” (page 43, ref 1)” (page 43, ref 1)

““Teamwork is much more important than the Teamwork is much more important than the sum of the individuals. With software teams, a sum of the individuals. With software teams, a project manager needs to configure a balance project manager needs to configure a balance of solid talent with highly skilled people in the of solid talent with highly skilled people in the leverage positions.leverage positions.” (page 43, ref 1)” (page 43, ref 1)

Staffing…Staffing… Staffing principles from Barry Boehm:Staffing principles from Barry Boehm:

The principle of top talent:The principle of top talent: use better and fewer use better and fewer peoplepeople

The principle of job matching:The principle of job matching: fit the tasks to the fit the tasks to the skills and motivation of the people availableskills and motivation of the people available

The principle of career progression:The principle of career progression: an an organization does best in the long run by helping organization does best in the long run by helping its people to self-actualizeits people to self-actualize

The principle of team balance:The principle of team balance: select people select people who will complement and harmonize with one who will complement and harmonize with one anotheranother

The principle of phase-out:The principle of phase-out: keeping a misfit on keeping a misfit on the team doesn’t benefit anyonethe team doesn’t benefit anyone

Staffing…Staffing…

In general, staffing is achieved by these In general, staffing is achieved by these common methods:common methods: If people are already available with If people are already available with

required skill set, just take themrequired skill set, just take them If people are already available but do not If people are already available but do not

have the required skills, re-train themhave the required skills, re-train them If people are not available, recruit trained If people are not available, recruit trained

peoplepeople If you are not able to recruit skilled people, If you are not able to recruit skilled people,

recruit and train peoplerecruit and train people

Staffing…Staffing…

Staffing of key personnel is very important:Staffing of key personnel is very important: Project ManagerProject Manager Software ArchitectSoftware Architect

Project ManagerProject Manager

Hiring Skills:Hiring Skills: Be able to get the right Be able to get the right person for the right jobperson for the right job

Customer-interface Skills:Customer-interface Skills: Avoiding Avoiding adversarial relationships among adversarial relationships among stakeholders is a pre-requisite for stakeholders is a pre-requisite for successsuccess

Decision-making skill:Decision-making skill: Hard to define, Hard to define, this is the most important difference this is the most important difference between an average manager and a between an average manager and a good managergood manager

Project Manager…Project Manager…

Team-building skill:Team-building skill: Teamwork requires Teamwork requires that a manager establish trust, motivate that a manager establish trust, motivate progress, exploit eccentric prima donnas, progress, exploit eccentric prima donnas, transition average people into top transition average people into top performers, eliminate misfits, and performers, eliminate misfits, and consolidate diverse opinions into a team consolidate diverse opinions into a team directiondirection

Selling Skill:Selling Skill: Must be able to sell all Must be able to sell all stakeholder of a project for the ultimate stakeholder of a project for the ultimate success of his projectsuccess of his project

Software ArchitectSoftware Architect

Technical Skills:Technical Skills: the most important skills for an the most important skills for an architect. These must include skills in both, the architect. These must include skills in both, the problem domain and the solution domainproblem domain and the solution domain

People Management Skills:People Management Skills: must ensure that must ensure that all people understand and implement the all people understand and implement the architecture in exactly the way he has architecture in exactly the way he has conceptualized it. This calls for a lot of people conceptualized it. This calls for a lot of people management skills and patience.management skills and patience.

Role Model:Role Model: must be a role model for the must be a role model for the software engineers – they would emulate all software engineers – they would emulate all good (and also all bad !) things that the architect good (and also all bad !) things that the architect does does

RecruitmentRecruitment

RecruitmentRecruitment

Seven golden rules of recruitment:Seven golden rules of recruitment: Recruit only if you can not get similar talent Recruit only if you can not get similar talent

from within the companyfrom within the company Never hire in a hurryNever hire in a hurry Always hire people smarter than youAlways hire people smarter than you Hire for attitude, train for skillsHire for attitude, train for skills If you have any doubt, better don’t hireIf you have any doubt, better don’t hire Hire people who dare to disagree with youHire people who dare to disagree with you Hire freshers from the college (~15%Hire freshers from the college (~15%

Recruitment…Recruitment…

Nowadays, hiring a mutual process – even the Nowadays, hiring a mutual process – even the candidate ‘selects’ the company he wants to work candidate ‘selects’ the company he wants to work with – so make sure that the interview process is not with – so make sure that the interview process is not like an ‘examination’like an ‘examination’

Look for the following while hiringLook for the following while hiring Merit – means the past performanceMerit – means the past performance Potential – means the capability to achieve results in the Potential – means the capability to achieve results in the

futurefuture Ambition – what does the person what to achieve in careerAmbition – what does the person what to achieve in career

For junior people, merit is more important, while for For junior people, merit is more important, while for senior people, potential is more important (on a senior people, potential is more important (on a relative scale)relative scale)

Watch out for fake / clichéd ambition, but never hire Watch out for fake / clichéd ambition, but never hire someone with low ambition someone with low ambition

Recruitment…Recruitment…

While hiring, try to hire senior people first – While hiring, try to hire senior people first – senior people are required for building the senior people are required for building the team, and junior people can always be in-team, and junior people can always be in-sourced / staffed during the later phasessourced / staffed during the later phases

While hiring, always hire the people who While hiring, always hire the people who are ‘star performers’ in their current are ‘star performers’ in their current organizations – it would inspire other good organizations – it would inspire other good people to join youpeople to join you

Training & MentoringTraining & Mentoring

Not all the people who join your team Not all the people who join your team might be experts, or even have above-might be experts, or even have above-average knowledge of your projects’ average knowledge of your projects’ technology – most of them would need technology – most of them would need some training or othersome training or other

Plan for the training upfrontPlan for the training upfront Mentoring ensures a good ‘hand-holding’ Mentoring ensures a good ‘hand-holding’

for newcomers to a team and culture-for newcomers to a team and culture-building in the teambuilding in the team

Role IdentificationRole Identification

The role must be identified depending on The role must be identified depending on these two factors:these two factors: Individual’s capability and interest must be Individual’s capability and interest must be

kept in mind as much as possiblekept in mind as much as possible Interest of the Project / Organization is always Interest of the Project / Organization is always

superior to the individual’s interest and superior to the individual’s interest and capability – in case of a conflict, the larger capability – in case of a conflict, the larger interest must be honored interest must be honored

Task AllocationTask Allocation

Ideally, each person must be able to choose Ideally, each person must be able to choose his / her task – this would motivate him / her his / her task – this would motivate him / her to give best performanceto give best performance

But, this might not be possible always due toBut, this might not be possible always due to Some team members joining the project late have Some team members joining the project late have

less choiceless choice Some team members asking for allocation of task Some team members asking for allocation of task

but they are not competent to perform itbut they are not competent to perform it Some task is already identified for a more Some task is already identified for a more

competent person who is yet to joincompetent person who is yet to join

Task…Task…

If the ideal task allocation is not possible, If the ideal task allocation is not possible, the PM should try to find the next best the PM should try to find the next best option / choice and allocate.option / choice and allocate.

If no option is available and the team If no option is available and the team member does not want to accept an member does not want to accept an alternate even in the interest of the project / alternate even in the interest of the project / organization, it is better not to take such organization, it is better not to take such person in the team – because he might person in the team – because he might never be a motivated team member.never be a motivated team member.

Managing Cross-cultural TeamsManaging Cross-cultural Teams

Big subject – many books have been written about thisBig subject – many books have been written about this In today’s context, the person who can manage in In today’s context, the person who can manage in

different cultural work styles is needed. It is not different cultural work styles is needed. It is not important if you personally subscribe to that way of important if you personally subscribe to that way of working or not !working or not !

Some personal experiences:Some personal experiences: European: meticulous, think of long-term plan / impact, very European: meticulous, think of long-term plan / impact, very

high productivity but not keen to overtime, high focus on high productivity but not keen to overtime, high focus on quality of life and familyquality of life and family

Chinese: go-getter attitude, emphasis is on hard work (rather Chinese: go-getter attitude, emphasis is on hard work (rather than on smart work), consensus-oriented management, than on smart work), consensus-oriented management,

Cross-cultural...Cross-cultural...

To me, the three most important things To me, the three most important things are:are: Ensure that there is no difference between Ensure that there is no difference between

the the expectationsexpectations and and evaluation criteriaevaluation criteria of of tasks between the people of different tasks between the people of different cultures just because of the culture cultures just because of the culture difference alonedifference alone

Focus on strengths of different cultures / Focus on strengths of different cultures / people – not on its weaknessespeople – not on its weaknesses

Treat everyone the sameTreat everyone the same

Reducing Team SizeReducing Team Size

Assuming that we have already reduced Assuming that we have already reduced the software size as much as possible, the the software size as much as possible, the primary techniques for reducing the team primary techniques for reducing the team size are:size are: OutsourcingOutsourcing In-sourcingIn-sourcing Improving ProductivityImproving Productivity Increasing the project scheduleIncreasing the project schedule Making multiple releasesMaking multiple releases

OutsourcingOutsourcing

Outsourcing could be an effective way to Outsourcing could be an effective way to quickly build a large team, and / or quickly build a large team, and / or manage peaks and valleys in the project manage peaks and valleys in the project lifecyclelifecycle

Personally, I think we should plan to Personally, I think we should plan to outsource 15% - 20% of work to de-risk outsource 15% - 20% of work to de-risk the projectthe project

Make sure you are not putting all your Make sure you are not putting all your eggs in a single basket !eggs in a single basket !

In-sourcingIn-sourcing

In-sourcing helps get the people only in In-sourcing helps get the people only in the phase when you require, and then the phase when you require, and then reduce them when you have less reduce them when you have less workload.workload.

I have worked with in-sourced team I have worked with in-sourced team members with mixed results. The success members with mixed results. The success rates were almost always ~50%rates were almost always ~50%

Don’t put too many of in-sourced people in Don’t put too many of in-sourced people in a single teama single team

Productivity Metrics ?Productivity Metrics ?

Productivity vs. SizeProductivity vs. Size

Improving ProductivityImproving Productivity Systemic / ProcessSystemic / Process

Direct: get it right the first timeDirect: get it right the first time• Do proper estimation, planning and schedulingDo proper estimation, planning and scheduling• Identify the right processes for the workflowIdentify the right processes for the workflow• Identify the right set of tools for the projectIdentify the right set of tools for the project• Orient the team members in the usage of processes and Orient the team members in the usage of processes and

toolstools Indirect: reduce the scrap and reworkIndirect: reduce the scrap and rework

• Allocate effort for rework effortAllocate effort for rework effort• Monitor and control the rework effortMonitor and control the rework effort• Ensure the reviews (at least the initial reviews) are very Ensure the reviews (at least the initial reviews) are very

rigorous – this way, you might get more rework in the rigorous – this way, you might get more rework in the early phases but you can perhaps reduce more rework early phases but you can perhaps reduce more rework in the later stagesin the later stages

Improving Productivity…Improving Productivity…

MotivationMotivation Task allocation as per people’s interest (might Task allocation as per people’s interest (might

not be always possible) and capabilitynot be always possible) and capability Make sure there are adequate amount of ‘offs’ Make sure there are adequate amount of ‘offs’

and ‘breaks’ – team building activities, formal and ‘breaks’ – team building activities, formal and informal gatherings, team dinners, etc.and informal gatherings, team dinners, etc.

Progress tracking must be ‘task-based’ rather Progress tracking must be ‘task-based’ rather than ‘time-based’than ‘time-based’

Improving Productivity…Improving Productivity…

EnvironmentalEnvironmental Peaceful, no-disturbance work areaPeaceful, no-disturbance work area No external interruptions for meetings, etc.No external interruptions for meetings, etc. All technical resources available readily to All technical resources available readily to

the team (Internet, library, manuals, etc.)the team (Internet, library, manuals, etc.) Office errand boy for Xerox, fax, etc.Office errand boy for Xerox, fax, etc. Pantry, canteen available within walking Pantry, canteen available within walking

distancedistance If need be, provide concierge service to If need be, provide concierge service to

employees in office itselfemployees in office itself

Increasing the Project ScheduleIncreasing the Project Schedule

Customer might or might not always agree Customer might or might not always agree for this, but it might be possible that “for this, but it might be possible that “…the …the Customer would tolerate 90% of the Customer would tolerate 90% of the functionality delivered late if they could functionality delivered late if they could have 10% of it on timehave 10% of it on time” (page 59, ref 1)” (page 59, ref 1)

At times, increasing the schedule might be At times, increasing the schedule might be a better way to improve the chances of a better way to improve the chances of success of a project rather than to address success of a project rather than to address it with hard work or with more manpowerit with hard work or with more manpower

Making Multiple ReleasesMaking Multiple Releases

When we make multiple releases, we might When we make multiple releases, we might mitigate the risk of a ‘late design breakage’ – we mitigate the risk of a ‘late design breakage’ – we could also use it to increase the project schedule could also use it to increase the project schedule thereby reducing the team size substantially thereby reducing the team size substantially without seriously impacting the product qualitywithout seriously impacting the product quality

The key is to identify the peripheral requirements The key is to identify the peripheral requirements that are probably “not so important” or “nice to that are probably “not so important” or “nice to have features” and deliver them in the next have features” and deliver them in the next release. For the first release, focus on the core / release. For the first release, focus on the core / key requirementskey requirements

Software ProcessSoftware Process

It is a myth that one single software It is a myth that one single software process can be defined and deployed for process can be defined and deployed for every kind / type / size of software projectevery kind / type / size of software project

Large projects needs large or ‘heavy’ Large projects needs large or ‘heavy’ processes; small project need small or processes; small project need small or ‘lightweight’ processes‘lightweight’ processes

Good planning involves good process Good planning involves good process planning, and selecting the right ‘weight’ of planning, and selecting the right ‘weight’ of the processes for the tasksthe processes for the tasks

Process...Process...

For example, in US Defense projects, the For example, in US Defense projects, the cost of a project might be up to 3 times the cost of a project might be up to 3 times the cost of a comparable commercial project - but cost of a comparable commercial project - but the business needs might justify such costs the business needs might justify such costs (mission-control systems, etc.)(mission-control systems, etc.)

One important thing while defining the One important thing while defining the process: Use your judgement to ‘interpret’ the process: Use your judgement to ‘interpret’ the process correctly for your needs. Don’t process correctly for your needs. Don’t assume that everything in the process is assume that everything in the process is always right !always right !

Process…Process…

Too much medicine can kill the patient !!!Too much medicine can kill the patient !!!

Chaos Bureauracracy

ProcessSpectrum

My Experiences: 2001My Experiences: 2001

We were building a Gigabit Switch Router (GSR)We were building a Gigabit Switch Router (GSR) Code estimate : ~600 KLOCCode estimate : ~600 KLOC Code actual : ~700 KLOCCode actual : ~700 KLOC Manpower estimate: 110+ (Dev) & 15+ (QA)Manpower estimate: 110+ (Dev) & 15+ (QA) Subcontracted around 50 KLOCSubcontracted around 50 KLOC PDT Kick-off to SRS: ~3 monthsPDT Kick-off to SRS: ~3 months SRS-MST: 6 months (late by 2 months !)SRS-MST: 6 months (late by 2 months !) Integration: 10+ months !!!Integration: 10+ months !!!

My Experiences: 2002My Experiences: 2002 We were building a Softswitch with 3G Wireless access We were building a Softswitch with 3G Wireless access

capabilities – kind of wireless + wireline softswitchcapabilities – kind of wireless + wireline softswitch First Code Estimate: 300 KLOCFirst Code Estimate: 300 KLOC Second Code Estimate: >500 KLOCSecond Code Estimate: >500 KLOC Final Code (actual): ~570 KLOCFinal Code (actual): ~570 KLOC Team: 145 (Dev) and 45 (QA)Team: 145 (Dev) and 45 (QA) PDT Kick-off to SRS: ~2 monthsPDT Kick-off to SRS: ~2 months SRS-MST: 3 months (wireline) to 6 months (wireless)SRS-MST: 3 months (wireline) to 6 months (wireless) Integration: 2-3 monthsIntegration: 2-3 months Field Trials: within ~2 months of completing DevField Trials: within ~2 months of completing Dev Commercial Orders: within ~2 months of completing field Commercial Orders: within ~2 months of completing field

trialstrials MST-TR4A: ~7 monthsMST-TR4A: ~7 months

My Experiences: 2003My Experiences: 2003 We were building Routing Platform with complete IPv6 We were building Routing Platform with complete IPv6

support, routing protocols (RIP, ISIS, BGP, OSPF, etc.) support, routing protocols (RIP, ISIS, BGP, OSPF, etc.) and complete MPLS supportand complete MPLS support

First Code Estimate: 300 KLOCFirst Code Estimate: 300 KLOC Second Code Estimate: 550 KLOCSecond Code Estimate: 550 KLOC Final Code (actual): ~ 600 KLOCFinal Code (actual): ~ 600 KLOC Manpower: ~120 (Dev) and 17 (QA)Manpower: ~120 (Dev) and 17 (QA) PDT Kick-off to SRS: ~3 monthsPDT Kick-off to SRS: ~3 months SRS-MST: ~6 months (delayed by only ~15 days !)SRS-MST: ~6 months (delayed by only ~15 days !) Integration: 1 month (90% complete). Integration: 1 month (90% complete). MST-TR4A: 4.5 monthsMST-TR4A: 4.5 months

ConclusionsConclusions

Being part of a large project is a blessing. I Being part of a large project is a blessing. I call it as the finishing school for software call it as the finishing school for software managers !managers !

I rate my own success rates as 50% (in I rate my own success rates as 50% (in 2001) to 80% (in 2003). You grow with 2001) to 80% (in 2003). You grow with every experience.every experience.

I did not cover many other important I did not cover many other important ingredients like communication, tracking, ingredients like communication, tracking, cross-team technical reviews, etc.cross-team technical reviews, etc.

Further ReferencesFurther References ““Software Project Management – A Unified Framework” by Walker Software Project Management – A Unified Framework” by Walker

RoyceRoyce http://www.computer.org/software/so1996/s4024abs.htmhttp://www.computer.org/software/so1996/s4024abs.htm ““Managing Software Engineers” - Managing Software Engineers” -

http://www.arsdigita.com/asj/managing-software-engineers/http://www.arsdigita.com/asj/managing-software-engineers/ http://ieeexplore.ieee.org/xpl/abs_free.jsp?arNumber=366170 http://ieeexplore.ieee.org/xpl/abs_free.jsp?arNumber=366170 http://www.itweb.co.za/sections/techforum/2004/0403160836.asphttp://www.itweb.co.za/sections/techforum/2004/0403160836.asp www.columbia.edu/~jm2217/Q7503_12post.ppt www.columbia.edu/~jm2217/Q7503_12post.ppt http://www.gantthead.com/article.cfm?ID=208820http://www.gantthead.com/article.cfm?ID=208820 http://www.processimpact.com/articles/proj_mgmt_tips.htmlhttp://www.processimpact.com/articles/proj_mgmt_tips.html http://www-106.ibm.com/developerworks/websphere/library/http://www-106.ibm.com/developerworks/websphere/library/

techarticles/0306_perks/perks.htmltecharticles/0306_perks/perks.html

QuestionsQuestions

Thank YouThank You