Managing Software Projects
Backdrop
Software today comes in several shapes and sizes. Commercial off-the-shelf (COTS) packages like
Office enable users to carry out desktop tasks such as word processing and spreadsheet manipulation.
Larger packages like SAP facilitate enterprise-level functions such as supply chain management and
HR. Systems software like a mobile phone stack brings a hardware device to life. Finally, custom
software like the IRCTC web site helps establish an interface between the customer and the
enterprise.
Each avatar of software is an outcome of close deliberations by a project team with a motley bunch of
stakeholders -sponsors, subject matter experts, QA groups, end users, and so on. This team is forced
to live inside a “tar pit” of incomplete requirements, premature development, shortened test cycles,
and last minute changes. Consequently, software projects tend to navigate choppy waters during much
of their lifecycle.
Well-published surveys of software implementations highlight a crisis: a good third of the projects are
cancelled midway. Few fingers are pointed at technology shortcomings. Rather, some familiar people
and process issues are the common culprits. Fred Brooks, a software legend, once declared that no
silver bullet can safeguard software projects against the essential monsters that haunt them. Many
decades later, his statement remains uncontested.
The Project Manager
A seasoned project manager (PM) deftly mixes process with people to get the job done. Encouraging
team members to focus on their mission, the PM ensures that their morale is not compromised in the
heat of delivering a system. One hallmark of a good PM is the ability to negotiate with stakeholders
without adversely impacting relationships. Developers are known to crave task variety, and are averse
to routine. Again, good PMs must know how to balance their expectations.
20th century software teams typically implemented projects using the waterfall process. In this
approach, a PM worked with senior clients to identify system requirements. System features were
fleshed out with a prototype, and critical risks were addressed. Post this, development commenced on
a mutually agreed baseline of features, with an expanded team. A change control board was
established to limit requirements creep. Periodic checkpoints offered stakeholders an opportunity to
study the progress.
The Agile Approach
The scenario portrayed may appear adequate. However, teams adhering to the model discovered that
it led to poor resource utilization and caused great client dissatisfaction. Whereas a client could have
benefited from a feature enhancement, the team was loathe to execute late arriving requests, due to the
impact they may have had on the code. Recognizing these concerns, an enlightened group of
professionals came together in 2001 to formulate the Agile Manifesto.
The Agile approach to build software is founded upon principles that underscore continuous customer
collaboration, openness to change, frequent releases, and self-organizing teams that improve their
process on an ongoing basis. Techniques such as extreme programming and Scrum embody the
philosophy of Agile, and are being embraced by teams and organizations worldwide, even on large
efforts.
Managing Software Projects: The Course
This 20-session course is designed for an audience with at least 2-years of acquaintance with the
software industry. The course has two main goals:
To appreciate process neutral aspects of software management, specifically with regards to system
requirements, scope management, and so on. To equip the participant with a working knowledge of
Agile. A hands-on project shall expose teams of participants to the dynamics of an agile effort
Here are some objectives on the people and process dimensions of software projects.









People Process
Facilitate meetings and brainstorms
Participate in a contract negotiation
Provide individual and team feedback
Manage the client relationship
Elicit and capture project requirements
Estimate the effort for a project
Schedule a project using the WBS
Establish quality assurance mechanisms
Make no mistake, this is an intense program on project management. It employs a mix of instructorled discussions, inputs from industry professionals, and participant insights. Exercises on
brainstorming, negotiation and estimation, captured on video for a debrief, shall give participants a
realistic feel for these “routine” activities. Finally, all participants are expected to work in small
groups on a tight-paced project assignment.
For a course on Managing Software Projects to have any substantive effect, a student must prepare for
each session (many will have caselets) and attend class at least 80% of the time. It's a course on
project management, after all!
Schedule
No. / Topic Assigned / reading
1 The World of Software
Brooks, Fred. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer
(1987)
2 What can go wrong?
McConnell, S. Rapid Development. Case on Classic Mistakes
3 Risk management
McConnell, S. Rapid Development. Case on Risk Management
Boehm, B. Software Risk Management: Principles and Practices. IEEE Software (1991)
4 Methodologies
Larman, C. Iterative, evolutionary and agile, in Applying UML and Patterns (2004)
5 Project requirements
Fairley, R. & Wilshire, M. Why the Vasa sank: 10 problems and antidotes for software projects. IEEE
Software (2003)
6 Refining requirements
Ross, P. The Exterminators. IEEE Spectrum (2005)
7 Brainstorm (Interactive exercise)
Doyle, M. and Straus, D. Facilitation from How to make meetings work. Berkley Reprint (1993)
8 The Agile Approach
Schwaber, K. The Scrum Guide
9 User stories
Web links
10 The Agile Workshop (Guest lecture)
Longstreet, D. The Agile Method and other fairy tales
11 Estimation
McConnell, S. Rapid Development. Case on Estimation
12 Planning Poker (Interactive exercise)
Web links
13 Software Costing
Venkatagiri, S: Destination Saptadweep
14 Negotiation analysis
Sebenius, J.K. The hidden challenge of cross-border negotiations. Harvard Business Review (2002)
15 Negotiation (Interactive exercise)
Case handed out in advance
16 Software Testing
Whittaker, J.A. What is software testing? And why is it so hard? IEEE Software (2000)
17 Project Metrics
Kulik, P. A practical approach to software metrics. IT Pro (2000)
18 Question of quality
Fishman, C. They write the right stuff. FastCompany (1996)
19 Peopleware
Web links
20 Presentations Project Presentations
A copy of Steve McConnell’s classic on project management titled Rapid Development1 shall be
made available to each participant. This book contains crisp caselets in a realistic software setting. We
shall be discussing the caselets daily. It is expected that the participants shall jointly work with their
respective project groups on these caselets.
Faculty Profile
Shankar Venkatagiri is a faculty member in the Quantitative Methods & Information Systems area at
Indian Institute of Management Bangalore (IIMB). His interests are in open source software, software
project management and educational technologies.
Shankar began his professional career at Sapient Corporation, Cambridge, where he consulted with
clients in the energy and healthcare sectors. He then developed bandwidth-efficient Internet
applications at Curl Corporation, an MIT-based technology start-up. As a senior consultant with
Reuters Consulting, he worked with brokerage firms and banks in the role of a solutions architect.
At IIMB, Shankar has chaired the long duration PGSEM program, which is targeted at professionals
in the software industry. With over six years of experience in the industry, he has developed a keen
appreciation for the various facets of software management. He has also conducted project
management training at prominent firms like NDS.
An alumnus of IIT Kharagpur, University of Southern California and Georgia Tech, Shankar holds a
doctorate in mathematics and a masters degree in computer science.
1 http://www.amazon.com/Rapid-Development-Taming-Software-Schedules/dp/1556159005