Underbelly Of Software Project Management Tools

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. Componentbased 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 [email protected]