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:

• Time: A project has to be time-bound, with well-defined start and end dates.
• Cost: Budgets allocated for the project have to be met.
• Quality: Not only should the project be completed, but the quality of the achievement has to be of a pre-determined standard.

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:

1. Planning Phase: This is the phase where the client and the team representing the software developers, usually the Business or Systems Analyst, interact. Requirements of the project are brought to the surface in detail. When both sides agree on the deliverables of the project, a formal document is prepared that is signed by the parties.

   At the end of this phase, risk assessment is performed to budget time for risks that might arise in the phases ahead.

2. Design Phase: For every requirement laid down in the formal document, a holistic, integrated design of the software is crafted in this phase. Managing software projects typically comprises coding, testing, customer support and documentation. Design is carried out for all these aspects.

   A timeline is created by the project manager based on the estimates from the design process.

3. Iterative Code/Test Phase: Requirements may be divided into “iterations” so that the project can be quickly delivered in stages, and the risk of the overall project is reduced.

   After completion of this work, user acceptance testing is carried out by team members who specialize in this work - and ideally different from the coders - by simulating user environment.

4. Production Phase: This is the phase that declares to the world that the software is ready. All formalities required to install the software at the customer site are completed in this phase.

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:

• Scheduling of tasks: In every phase, tasks are identified; each task is broken down into sub- and sub-sub- tasks; and they are linked and their dependencies identified.
• Managing Software Projects resources: Resources in terms of skilled manpower, hardware and software infrastructure, and any other situation-specific resource (such as a functional/domain expert from the client-side) have to be organized and coordinated.
• Collaboration: This activity is especially crucial in case of geographically-dispersed groups. Shared web-pages, threaded discussion boards, integrated emails are a few implementations that help people collaborate with each other during the life of a project.
• Tracking time: To ensure that projects are not overshooting the time being allotted to them, this component is a vital meter on the manager’s dashboard.
• Estimation: On-the-toes “what-if” analyses, cost projects of time and money - where previous experience plays a big role, removes any complacency that can lull the manager.
• Assessing and managing risks: Without putting the manager and the team members into a pessimist frame-of-mind, this component forces all concerned to be aware of possible risks and acknowledge their existence, and work proactively on their resolution.
• Reporting and Charts: The more precise and informed charts that can be generated in a jiffy, the better is the control of the manager over the project.
• Processes and methodology: Process workflows have to be continuously monitored and deviations and blockages, if any, have to be addressed well in time.

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:

• Microsoft’s EPM solution
• Oracle Projects
• Rational Concepts’ I-Schedule
• ProductSoft
• Vertabase

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.

Return to Software Project Management