management of large software projects tathagat varma mindtek, 25-mar-2004
Post on 19-Dec-2015
214 Views
Preview:
TRANSCRIPT
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
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.
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
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 !
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…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
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
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
top related