Underbelly of Software Project Management Tools

Introduction

Tiger is a strong, ferocious and carnivorous animal. The only weak part of its body is its
underbelly. The easiest way to kill a tiger is by attacking its underbelly but the hitch in
reaching the underbelly is that it is protected from attacks by tiger’s claws, two-inch long
canines, the powerful paws and its well-honed killer instinct.

The tools for managing software development projects in the software industry are also
like the tiger – powerful yet with an underbelly. The purpose of this article is to look at
that underbelly.

Software tools that are being used in the software development project management fall
into two categories, namely,

1. Scheduling and tracking tools, such as MS-Project and Primavera

2. Document Management tools such as Whizible and Digite

Let us look at the underbellies of these two categories.

Pedigree of Scheduling and tracking tools

After the success of PERT in the Polaris Nuclear Submarine development was well
publicized, PERT became darling of the industry and it was adopted in a big way. When
PCs started having respectable graphics capability, PERT/CPM based packages are
developed and offered. The first one I saw was the HTPM (Harvard Total Project
Manager). I loved it as it allowed me to draw network diagram interactively. Then it
became HTPM II and HPM (Harvard Project Manager) and then disappeared. Primavera
also came about the same time and it took root in the construction industry and is the
major player in that segment. Then came a plethora of packages from India but none
could make much dent in the market.

Then came MS-Project by studying and improving all the existing products and then
bringing out a killer app, in the true tradition of Microsoft. MS-Project is more or less the
de-facto standard for project management tools in the software industry so much so that
PMI (Project Management Institute) made it a subject of study for getting certified as
PMP (Project Management Professional). I am amazed at this decision – are we saying
that those who are proficient in Primavera cannot be certified as PMPs?

Present market leaders are MS-Project and Primavera.

Pedigree of Document Management Packages

Unlike in other industries, in the software development industry placed very high value
on certifications, such as ISO 9000 (International Standards Organization’s 9000 series
of standards) or SEI’s CMMI (Software Engineering Institute’s Capabilities Maturity
Model Integrated). In order to obtain certifications and to maintain them, the
organizations need to gather evidence of continued conformance to the standards /
models of the certifying organizations, especially the ISO and SEI. The onus of
maintaining these documents is mainly with the project manager and with the quality
department of the organization.

While MS-Windows and UNIX both allow secure management of documents, project
managers wanted tools to manage the project documents. Microsoft obliged with VSS,
which can be used for document control though its original intent was to control the code
under development. Others too followed in quick succession. They were titled SCM
(Software Configuration Management) tools and not as Project Management tools on the
one hand and are not directly aimed at making the certification / surveillance audits
easier to face. Couple with this, the penchant of the software developers and
managements to see every thing in a browser and having it on the Internet / intranet,
gave rise to new breed of document controllers under the garb of Project Management
tools.

These packages are mainly document controllers and integrate MS-Office tools such as
Word, Excel and MS-Project. They also provide mechanisms to manage the work
register and set of rudimentary metrics such as schedule variance.

Software estimation functionality is almost non-existent in these packages. Component-

based tracking is also absent.

Task Centric Vis-à-vis Component Centric of Scheduling and tracking tools

These scheduling & tracking tools are based on PERT / CPM (Program Evaluation and
Review Technique / Critical Path Method). PERT came out of research background from
the development of Polaris project from the US Department of Defense and is intended
to handle the uncertainty inherent to the research project and predict the completion
date. CPM came out of construction industry and is intended to predict the completion
date and possibly to pre-pone the completion date by infusing more resources. Both
techniques are based on network diagrams. The underlying premises of these two
techniques are that

1. A project comprises of a finite number of activities (tasks, if you prefer)

2. A network diagram connecting all the activities between start activity and activity
is central to the techniques
3. Completion of those activities would complete the project
4. Some activities can be performed concurrently with each other and some need to
be performed sequentially
5. There could be several paths from the start activity to the end activity in the
network diagram and the path that takes the longest duration is called the critical
path
6. The activities that fall on the critical path are called the critical activities and any
delay in the completion of critical activities would delay the project
7. The activities that do not fall on the critical path would have some slack (float)
and delaying their completion date within the available slack would not delay the
project
8. Activities consume resources including time (measured in duration not effort)
9. The sum of the cost of those resources is the cost of the project
10. All the activities have precedence relationships with each other
11. The project has a definite start and a definite end
As you can see, “activity (task) is central to these techniques! So these techniques
revolve around tasks, scheduling tasks, determining which tasks can be delayed and
identifying the resources needed for those tasks, tracking the completion status of tasks
and progress of the tasks that are started but not completed.

This is perfect for construction scenario as that industry is activity based – there would
be large number of disparate tasks. Quality assurance is basically “in-process”
inspection. Testing has very limited application – limited to testing the electrical wiring
and plumbing and even there, it is cursory. In-process inspection is crucial. The quality
control inspector works along side the workers performing tasks ensuring that the tasks
are performed properly. For example, while pouring concrete, quality of materials and
method of mixing, quality of the mix and the method of pouring have to be ensured on
the spot and immediately. Once poured, the inspector has no role – reversal or the work
results in loss of costly resources like materials. Quality assurance is not a sequential
separate activity but an embedded and concurrent activity. Thus, if we have an activity
“Pour Concrete” it includes all relevant quality control activities too. Quality control is a
miniscule portion of the activity.

Now cutover to software development industry – software development hinges on

components like screens, reports, stored procedures and so on. The tasks are few such
as requirements, design, coding and testing with lion’s share going to coding and testing.
Construction of these components, integrating them into a product and testing it to
ensure that desired functionality and quality are built-in, completes the project. Here
quality control is sequentially performed. That is, we construct a component like screen,
then we subject it to peer review and independent testing. Then integration of all the
components and then, final testing comprising of multiple tests is carried out by
independent peers. Quality assurance consumes significant amount of time and in some
cases, quality assurance takes more time than performance itself.

So software development industry tracks the project using components mainly and not
tasks!

Second, activities in construction industry consume resources (materials, specialized

equipment etc.) besides human resources. Software development industry, the main
resource is human resource and other resources are minimal or absent.

PERT/CPM based tools do not facilitate component based scheduling. It does not
facilitate (easily I mean) scheduling quality control activities against the component
except as a separate task unrelated to the component. This renders tracking by
component difficult.

Therefore, these tools that are based on PERT/CPM, being task-centric are not the best
fit for software project management.

We circumvent this major hitch by adding quality assurance activities also as separate
tasks. Well, this is a workaround but surely not the most suitable or appropriate for
software development projects.

Duration Centric Vis-vis Effort Centric

Construction industry puts emphasis on duration, as other resources are more critical
than human resources. Human resources are replaceable not equipment. In software
industry, human resource is the most critical and costliest resource. Human resources
cannot be easily replaced without impacting the completion date. Therefore, more
emphasis is placed on effort than on duration.

We estimate the effort required for a task and allocate one resource, we expect that the
duration would be equal to effort plus intervening holidays if any and if we allocate two
resources, we expect the duration to be halved. In these packages, the duration remains
the same. That is because these packages are duration centric not effort centric.

We circumvent this hitch by manually reducing the duration when we allocate more
resources to the task. Well, this is another workaround but surely not the most suitable
or appropriate for software development projects.

Duration estimation vis-à-vis size & effort estimation

These packages do not provide for effort estimation - directly. Well, they give us the
duration estimation. There is a workaround available in these packages – it gives us the
quantity of the resources required and we need to sum up the requirement of human
resources, allocated to tasks. Well, this is another workaround but surely not the most
suitable or appropriate for software development projects.

Another aspect is that the estimation of effort as described above is based on what may
be construed as Task (activity) Based Estimation. It does not provide for software-size
based effort estimation or Analogy Based estimation or Delphi Estimation – all these are
very popular in the software development industry.

Software size is required if we are to derive the productivity of software development

activities in the organization. In construction industry this is not a concern as in
PERT/CPM terms, construction industry is called deterministic (meaning that the
productivity figures for construction activities are well established and known to all the
concerned).

What practically happens is that software effort either directly or thru size, is estimated
separately and it is retrofit into these packages, which really does not fit well. So project
managers end up tracking effort and schedule separately.

Final words

A project management tool ought to start with estimation – size estimation, effort
estimation and cost estimation. Then it should cater to building a work breakdown
structure enabling component-based tracking and task-based tracking. It also ought to
cater to quality assurance activities within the workflow and cater to defect management.
Changes are common to any software project and the tool ought to cater to change
management. It also ought to capture actual time spent by human resources. It ought to
give software metrics, namely, productivity metrics, defect metrics, schedule metrics,
effort metrics and change (requirements stability and scope creep) metrics.

Unfortunately the above classes of software project management tools, which account
for 99% of the market, do not provide all these.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
About the Author:

Murali Chemuturi is a Fellow of Indian Institution of Industrial Engineering and a Senior

Member of Computer society of India. He is a veteran of software development industry
and is presently leading Chemuturi Consultants, which provides consultancy in software
process quality and training. He can be reached at murali@chemuturi.com