Project Management A Practical Approach Sridhar Pandurangiah Director - Engineering Sridhar Pandurangiah Director - Engineering

Truths… Well-managed projects sometimes fail; Badly managed projects inevitably fail Adding manpower to a late software project makes it later. That is, people and time are not interchangable in software development

More truths… Good project management is essential for project success The intangible nature of software causes problems for management Managers have diverse roles but their most significant activities are planning, estimating and scheduling Planning and estimating are iterative processes which continue throughout the course of a project

Many more truths… Estimating the difficulty of problems and hence the cost of developing a solution is hard Productivity is not proportional to the number of people working on a task Adding people to a late project makes it later because of communication overheads The unexpected always happens. Always allow contingency in planning

Some more truths… A programming systems product takes about nine times as much effort as the component programs written separately for private use All programmers are optimists. Because the programmer builds with pure thought-stuff, we expect few difficulties in implementation. But our ideas themselves are faulty, so we have bugs Our estimating technique, built around cost- accounting, confuse effort and progress

Some more truths… Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication A small sharp team is best – as few minds as possible (3 – 8 members) Schedule disaster, functional misfit, and system bugs all arise because the left doesn’t know what the right hand is doing. Teams drift apart in assumptions

Some more truths… For most projects, the first system built is barely usable: too slow, too big, too hard to use, or all three Hence, plan to throw away; you will, anyhow Some valid changes in objectives (and in development strategies) are inevitable, and it is better to be prepared for them than to assume that they will not come

Some more truths Similar projects does not mean same project I.e work is unique. ALWAYS!

Some basic skills Define Project Plan Work Manage the workplan Manage issues Manage scope Manage risks Manage communication Manage documentation Manage quality Manage metrics

Define a Project Project Team, Management and client should have common perception of what would be delivered, by whom and when. Check the project initiation for effort break-up Identify all requirements from the RFP / SRD List down all commitments made by Nucleus RE-ESTIMATE Call for a project board meeting

Plan the work… Prepare the schedule for the effort estimated –Identify resources –Plan leaves and holidays by creating separate calendars for these resources –Tasks should be broken up to sufficient level of detail –Don’t meddle with end dates, provide the start date, resources and effort the end date and duration are automatically calculated –Identify predecessors –Remove over-allocation –All SQA audits, weekly meetings should be identified –Identify critical path

Plan the work Prepare the Software Development plan Prepare the S-curve Rework on the activities if the s-curve doesn’t look like a “S”

Manage the workplan Having planned, Don’t sit back and relax! Track schedule daily, not weekly Update the SDP weekly Create a “weekly progress report” Report to management using the MCM report Report to client using an agreed format

Manage Issues Have an issues list circulated to all stakeholders This helps keep the focus

Manage Scope Don’t accept small changes just to please somebody Don’t change / enhance features during the current development cycle. Schedule it for the next cycle Managing scope is everyone’s responsibility

Manage Risk Be proactive All Systematic risks are to be managed Track risks in the WPR, the SDP and the Phase End report

Manage Communication Identify Distribution list and mechanism Team members – Minutes Of Meeting, Phase End Reports IBU Head – Weekly Progress Report, List of Issues Management – MCM Report Client – MOM, List of Issues BDG – List of Issues, Success Stories, Image building

Manage Documents Manage documents using the same configuration management tool that you use to configure your code Have a “Document Master List” and a “Document Distribution List” Manage your s

Manage Quality… A good quality car doesn’t always mean a ROLLS ROYCE! Figure out how much the client can afford Identify a defect prevention co- coordinator for the project team Discuss DP activities in weekly meetings Analyse causes of defects not only at every phase end but during every weekly meeting

Manage Quality Pursue quality relentlessly Quality is everybody’s responsibility Define quality objectives of team members in their KRA’s

Manage Metrics Source of metrics should be DRF’s and Timesheets Identify the few activity codes that you will use for each phase of the project Encourage team members to fill in task details rather than summary. This is essential to calculate the “Cost of Quality”

Conclusion The purpose of organization is to reduce the amount of communication and coordination necessary Even on a small project, the manager should from the beginning formalize a set of required documents An incremental-build model is better People are everything (well, almost everything)

Resources

Resources…

Resources

Resources

Resources

Resources

Thank You