Managing Software Projects - Not for the weak-hearted
I. Managing software projects: Background
Every one of human endeavor may be viewed as a project in itself, whether it is launching a rescue operation for victims of Katrina or Rita, flushing out a most-wanted terrorist, sending a manned shuttle to space and bringing it back safely, or conducting the morning assembly of students in the local school smoothly and consistently well.
Each one of them has specific start and end date/times, specific resource requirements in terms of manpower, material, and money (the 3Ms), and with specific objectives or goals before its managers and team members.
This article presents an overview of how managing software projects is supposed to be. Within the project management domain, managing software projects have their own unique characteristics, which have been sought to be highlighted.
II. Basics of the project game
Project management, or PM, must have been an unheard of term to the engineers who designed and built the Great Pyramids in Pharaoh’s time eons ago. Yet, their projects have endured the ravages of time, and are a source of awe and inspiration for managers even today.
Today, the subject has taken on an aura of its own. People have carved a career for themselves as project managers, and this discipline is now standard part of curriculum taught in B-schools. Institutes have come up that focus on developing world-class project management professionals through a rigorous training process followed by continuous upgradation.
Boiled down to the basics, managing software projects works on meeting the three vertices of this triangle:
Managing software projects, as a subset within the general project management umbrella, work within these three vertices. However, unlike other project domains, software is an invisible entity, an “ethereal thought-stuff”. When a bridge is being constructed, general public – the end users – passing by can very easily evaluate the work in progress, and can compare the contours of the framework coming up before their eyes with the architect’s blue-print. In the case of software, however, the end users – such as passengers booking their tickets online – do not get to taste the fruits of the team’s labor before it has actually been implemented.
Managing software projects has come a long way since Frederick Brooks wrote his classical book, The Mythical Man-Month. From a one-man team of system-analyst/programmer/implementor/customer-support, to small, cohesive teams interacting with the end-users during the design/development/testing stages, to huge 500-member work-forces, to multi-location/geographically-dispersed, “chasing the sun” collaborative groups that work round the clock to finish projects before time, the environment and ambience generally associated with developing and delivering software products and solutions is totally different from what one encounters in other domains.
III. Phases in managing software projects
Every software development goes through a “life-cycle”: there is a cyclical approach that, after reaching the final end of the project, leaps back to the starting point. (Ever heard of demolishing a bridge, okay a part of it, and reconstruct it all over again? They have a linear, non-cyclical model of start - progress - end.) This is because software, once available to end-users, may witness continuous enhancements and upgrades in order to meet changing user requirements and business conditions. (That is why Microsoft Windows is currently in its present avatar – the XP – and yet another iteration – the LongHorn – is due to be launched soon.)
There are several life-cycle models that are in vogue, each with its own merits and demerits, which handle the project life-cycle.
Following is a micro-description of the so-called “Waterfall” life-cycle model, which is how software development and delivery has traditionally been managed:
IV. Other popular Managing Software Projects models
When the Waterfall model began showing deficiencies in a percentage of cases, other life-cycle models were evolved that sought to provide more efficient substitutes.
Amongst these are Rapid Application Development (RAD), Extreme Programming (XP), Unified Process (UP), and the like. These models are solutions for specific customer requirement scenarios; and which particular model lends itself as candidate for a given case in hand is a challenge for the project manager to attack upfront.
V. Components that go into managing software projects
While the micro-description provided above on the “Waterfall” model is a simplified version, in actual practice a lot of activities go in each of the phases, enough to trip up a project manager who is anything less than vigilant. Some of the activities that they have to handle, irrespective of the life-cycle model, are as follows:
VI. Tools for management
There are two kinds of automation tools that help in managing a few or all of the components listed above: one that are available internally to an organization’s environment, and the other that are web-based and hosted, incurring monthly service charges. These softwares cater to the demands of both the team manager with fancy, red-yellow-green blinking “dashboards”, and the developer with filtered to-do lists and apropos reminders.
Examples of tools available currently in the market are:
VII. Final word
While managing software projects has always been a daunting job, another dimension has been added in recent years, with the increasing trend towards collaborative effort, bringing together best-of-breed expertise from personnel coming from diverse cultures. It is not uncommon a scene to have the project manager sitting in Silicon Valley scheduling tasks with one development group in Bangalore, another one in Shanghai, and yet another one in Lausanne.
For every success that is notched up in software project management domain, there are scores of others that litter the economic wasteland – because they had cost and time overruns, or because their specifications were not met fully or there were changes in specifications that were accepted midway into the project, there was turnover of key personnel because the HR manager botched their job, and so on –; to use another metaphor, it is a minefield that the manager needs to step carefully upon.
Managing software projects is definitely not for the weak-hearted.
Free eBookSubscribe to my newsletter and get my ebook on Entity Relationship Modeling Principles as a free gift:
What visitors say...
"I just stumbled accross your site looking for some normalization theory and I have to say it is fantastic.Read more Testimonials
I have been in the database field for 10+ years and I have never before come across such a useful site. Thank you for taking the time to put this site together."
Theory & Practice
SQL Server DBA
Install SQL Server
Database Normalization eBook:
Copyright © www.databasedesign-resource.com / Alf A. Pedersen
All rights reserved.
All information contained on this website is for informational purposes only.
Disclaimer: www.databasedesign-resource.com does not warrant any company, product, service or any content contained herein.
Return to top
The name Oracle is a trademark of Oracle Corporation.