Designing software project management models based on supply chain quality assurance practices Gautham Reddy N

Tata Consultancy Services Ltd, Boston, MA, USA

gautham.reddy@tcs.com

Abstract:

This paper is a project progress report of an innovative approach to software process improvements. It starts with a theory that whether some of the supply chain quality assurances practices be put into software projects as part of improving their development efficiencies. This paper is a snapshot of the events of this project. It starts with analyzing processes in various complex software projects. A test script automation project was chosen. This paper gives details on the factors on which the choice was made, how the process bottlenecks were identified and how a process improvement solution was designed. This process improvement solution includes a project management model which is capable to take into account all the new variables and provide the ability to track and monitor the process improvements made from this model, hence providing a productivity analysis capability. An excel workbook which was custom designed as part of the solution is also part of this paper. This excel workbook is where the project team members would enter the various times and is used by the project managers to estimate, track , monitor the productivity of the team in improving the delivery efficiencies in time and quality. In short, this is a snapshot of how a process improvement model can be designed which has a productivity analysis capability for a self feedback. This paper also describes the human factors such as reluctance to change and the overhead for the project members. This paper is an attempt to customize the regular project management techniques to target the process inefficiencies of complex software projects. This paper also provides of how to use customizations such as projects like these to create more generic models for process improvement solutions which have more robust productivity analyzing capabilities.

1. Introduction

In today’s world of software development, projects are becoming increasingly complex in terms of their lifecycles and the processes within their lifecycles. This paper is an example where one such complex software project was taken up for processes improvements. The hypothesis is that software development can be considered as an elementary supply chain where the development is considered as the main supply chain. The inputs to development are considered feeder chains with varying capacity. The output from the development chain is fed into receiver chains. The idea is that if software project management model is designed in such a way that the capacity of the feeder and receiver supply chains is a function of the main supply chain, improvements in process efficiencies are possible. By following some of the supply chain quality assurance practices, the model can be designed to place quality buffers in various feeder and receiver chains. The solutions design takes into account all the variables to make sure this software supply chain delivers software product as efficient as possible.

2. Project selection parameters The project selection criterion was based on the

hypothesis that whether some of the supply chain quality assurance practices be applied to conventional software development projects. The idea was to consider software development as a supply chain and all inputs as feeders. In this way, to identify the process bottlenecks for this software project and design a project management model specifically to improve the supply chain efficiency. Hence the criteria of selecting a software project to cater to the above requirements were that the software project should be delivering software output which has multiple inputs i.e.,

a) the project with multiple sub projects in itself with varying business priorities,

2009 World Congress on Computer Science and Information Engineering

978-0-7695-3507-4/08 $25.00 © 2008 IEEE

DOI 10.1109/CSIE.2009.953

659

2009 World Congress on Computer Science and Information Engineering

978-0-7695-3507-4/08 $25.00 © 2008 IEEE

DOI 10.1109/CSIE.2009.953

659

b) these sub projects having varying technical complexities,

c) Sub projects having multiple sources of requirements,

d) Sub projects controlled at a single place but are developed by multiple sub teams.

Hence the search was for a project which has the capability to deliver multiple software applications but the process of how to prioritize, plan and execute a central management model for this entire project has process inefficiencies. Many complex projects with multiple teams and total team strength of more than 50 and with more than 10 software applications to-be delivered were considered.

3. Project overview- processes bottlenecks Finally, a test script automation project which has to

develop automation test scripts to 11 different applications was chosen. Each application had different business priority and different technical complexity. The requirements for automation of test cases include

a) the functional understanding of the application,

b) the stabilized manual test cases, c) the User interface (UI) related technical

understanding such as if Ajax frame work used, the kind of grid for which the automation test script to be written,

d) the database related information of the kind of test data that’s needs to be fed as part of automation scripting,

e) Understanding what functionality of the application needs to be test script automated with provision of what kind of data customization ability(parameterization)

Requirements were mainly obtained from manual test teams for each application. Hence there were at least 11 different sources of requirements, as at times for a single application requirements were gathered from more than one team. There was this central automation team which whose task was to automate all these 11 different applications with 6 development members divided into 3 different sub teams. In this paper, the developing of automation test scripts for the manual test cases for each application is considered a development activity. The most critical variable of this project was ‘varying business impact’ to the customers based on ‘which application is being developed (automated) at what time of the project’. There was a constant pressure on re-prioritization of the project goals and timelines, as different application owners belonged to different verticals of the client organization.

The main process bottlenecks to successfully automate an application, for this project were

a) The prioritization factors of why a certain application should be first chosen over others for development were not clear. Hence there were no clear process parameters to streamline.

b) The functional requirements were coming from various sources at once but the quality of the requirements was good to start development.

c) Automation was seldom considered as a full development project. There was no comprehensive check on the quality of the automated test scripts. There were no proven comprehensive techniques to test automation scripts designed to test applications.

d) The estimation process needed more streamlining. The randomization of time by all the teams involved was never considered as part of requirements gathering process.

e) There were no clear SLA’s (Service level agreements) set or maintained to check for the effectiveness of automation of test cases for each application.

Due to these bottlenecks the project was not able to deliver high quality test automation scripts for applications. Rework on the test scripts was high and sporadic. The randomization of time of all the team members was high and unaccounted for. The clients’ satisfaction was very low and the risk of closing the project was high.

4. Design of the project management model

The project management model to- be designed had

to take all the variables of process inefficiencies and target each of them. The main idea was to put in place some of the elementary supply chain quality assurance practices. To do this, the entire process of the software project was divided into different phases where each of these process bottlenecks occur and then targeting each bottleneck in its phase by putting quality assurance filters. The output from each such quality assurance filter was a quality buffer. This quality buffer had to be made quantifiable for it to be measured and tracked for its effectiveness. With these parameters, the project management model had 4 distinct phases with quantifiable quality assurance buffers. An excel workbook was created as a part of the design of this project management model. This provided the ability for both team members and project managers to estimate, track and monitor the quality assurance filters placed in each of the defined phases. The full solution

660660

had other managerial and team level changes to make this model successful.

4.1. Prioritization phase The process bottleneck targeted in this phase is ‘prioritization of applications’ and test cases to be automated (developed) within each application. The following sequence of steps is the guidelines designed for this phase:

a) Analyze each application in terms of its business priority, functional complexity and technical complexity

b) Prepare individual priority list based on each of the above parameters.

c) Combine the three lists together and come out one final list. To do these activities negotiate with business partners, functional teams and technical teams to access the right priority.

d) The output of this phase is the final list of prioritized applications signed off by all the stakeholders as the right priority of the applications.

e) The supplementary output of this phase is breakup of tasks of (at least) the first application. As in this case it is the list of the test cases that need to be automated for the application.

This phase ensures that the goals for the project are clear and the project/iteration plan can be prepared on quantifiable goals.

4.2. Requirements sign off phase After the prioritization phase, with the list of applications ready, the development team takes up the first application of the list to develop automation test scripts. The process bottleneck targeted in this phase is streamlining and freezing the requirement gathering process. The main issue was the multiple channels of requirements and changes to the requirements. The following sequence of steps is the guidelines designed for this phase:

a) The list of breakup of tasks of the application to-be developed (in this case the list of test cases) are published to all stakeholders.

b) The stakeholders and the different channels of requirement inputs are identified and a ‘requirements sign off date’ is agreed upon. [The entire list of tasks for the application need not be signed off by the requirement

teams all at once. As the project is in agile mode, the requirements for (at least) the first iteration need to be signed off on an agreed upon date before the development of iteration1 sub tasks (to operate the main supply chain in minimum capacity). [More details below in section 5.2]

c) The output of this phase is that the requirement teams publish all the tasks for the iteration as ‘signed-off’ within the sign off date set by the development team and also enters the time taken for requirements sign off for each task.

This phase ensures that the requirements for the iteration are standardized and freezed by the requirements stakeholders, hence the development team always gets the signed off requirements within the set date.

4.3. Automation sign off phase After the requirements sign off phase, the development team starts automation of test cases (developments of the tasks) for the iteration. The process bottleneck targeted in this phase is streamlining and tracking the development activity for the iteration. The following sequence of steps is the guidelines designed for this phase:

a) The development team plans for the iteration and publishes the list of sub tasks (which are signed off by the requirement stakeholders) as development tasks for the iteration and with an end date to each task and assigns to the individual developer.

b) The final output of this phase is that each developer completes the tasks and enters the time taken to complete and publishes the completed tasks of the iteration.

This Phase ensures that the development team plans and completes the iteration development tasks complying with the project management goals set.

4.4. Quality check sign off phase After the development completes development of the tasks for the iteration, the deliverables have to be quality singed off in this phase. The process bottleneck targeted in this phase is the non standardization of quality check processes for this project. As it was testing of automation test scripts of the manual test cases, no known comprehensive quality sign off

661661

practices were identified. Mostly, the developers would themselves do the testing which was not comprehensive. Hence a quality sign off team was set up which consisted of members from different teams. The team’s task is to deploy these scripts and test them and close each of them as ‘quality signed off’. The following sequence of steps is the guidelines designed for this phase:

a) All the tasks singed off by the development team are taken up and tested for quality. The sign off date for the tasks is agreed upon.

b) If the script fails, the development team is intimated of the defects in the script developed. The time taken by both quality team and the development team on re-work on each task (script) is entered.

c) The final output of this phase is that each deliverable from the development team is tested for quality and signed off as quality assured with time taken for quality assurance noted.

This phase ensures that the iteration deliverables are quality signed off through a standard process.

5. Implementation The implementation of the project management

model described above was additional management activity on top of the existing project management. The attempt was to embed this into the existing one and to minimize the time spent by managers and team members to use this model.

5.1. Estimations After the prioritization phase, the list of applications

to be developed was obtained and the list of sub tasks for (at least) the first application was available. Taking this list of sub tasks of the first application, the development team had to estimate the time required to complete each sub task. Historical data available for the development was used as the estimation technique. The historical data available at that point of time was varying as there were no standard processes guiding the development. To ensure better estimates, all the historical data points were divided into simple, medium, complex sub tasks(in this cases sub task was developing automation scripts) and the average was taken to come up with numbers for simple, medium and complex sub tasks. The entire application was now estimated by categorizing each sub tasks into simple, medium and complex and estimating by putting in the average numbers obtained from the historical data.

5.2. Work break down structuring Now with estimates for developing each sub task

for the application, iteration planning was made by considering the development of automation as the main supply chain and the requirement phase is considered a feeder chain and the quality sign off phase is considered a receiver chain to this main supply chain. Hence, the development iteration is chosen in such a way that the total sub tasks chosen for development in iteration are less than the total sub tasks fed to development team through the requirement sign off phase. This is to ensure a buffer or stack of feed ready for development. Ideally, the margin of safety is to have a buffer of 2 times the iteration capacity. Hence the feeder chain is operated to have a capacity of at least twice that of the main supply chain and has the minimum buffer of 2 times the full capacity of main supply chain.

The quality sign off phase is considered as the receiver chain and is built to (at least) handle the minimum capacity of what is being fed by the development chain. Ideally, the margin of safety is operating the quality sign off chain at 1.5 times the maximum capacity of the development chain. Hence the receiver chain is operated to have a capacity of at least 1.5 times that of the main supply chain.

Both the margins of safety should be configurable to adjust the operational capacity of the entire supply chain in the future. Hence, iteration planning has to take into account the capacities of the feeder and the receiver buffers for its work breakdown structuring.

5.3. Project tracking With the iteration plan made, all the data is entered into the excel work book created to manage the model. In this workbook, the WBS data is entered for each sub task with its estimated end date for requirements sign off, automation sign off and the quality sign off. The estimated effort for the development is also entered. As the project starts each individual team member would open this sheet and fills up the different times as follows:

a) The requirements team member would complete the sub tasks on or before the estimated requirements sig off date set and enters the end date and the actual effort taken for completing this task.

b) For all the requirements signed off sub tasks, the developer completes the development on or before the estimated development sign off date and also enters the actual effort taken for developing the sub task.

662662

c) For all the development signed off sub tasks, the quality team member deploys them and tests them. If any errors discusses them with the development team member and closes the sub task by entering the end date , the time required for quality checking and the time required on rework (in case, the sub task had re-work).

With this data, the following project parameters are analyzed and tracked.

a) Estimated sign off dates and actual sign off dates of sub tasks in each phase of the iteration. This was crucial data to monitor and control the completion of iteration in time by making sure the main supply chain is operated at full capacity.

b) Margin of safety in requirements sign off phase and in quality sign off phase. This is monitored to ensure the feeder and receiver chain are always operated in conjunction with the main supply chain with set buffer.

c) The estimated effort vs. actual effort is tracked and monitored. This is crucial to use this data as standardized historic information to estimate and plan for the future iterations.

5.4. Results The productivity data was analyzed to understand whether or not this process improvement project had improved the processes. The month wise productivity data for the first 3 months is as follows:

a) % completion of iteration tasks within the iteration = 55%(Month 0), 59%(Month 1), 62%(Month 2), 69%(Month 3)

b) % rework on iteration tasks for the iteration = 34%(Month 0), 29%(Month 1), 24%(Month 2), 19%(Month 3)

c) % deviation of estimated time Vs. actual time of development for the iteration tasks = 26%(Month 0), 25%(Month 1), 20%(Month 2), 12%(Month 3)

6. Generalization and ideal scenarios This project management model can be generalized

to all complex software projects which can be divided into the main supply chain and which have one or more

feeder and receiver chains. This model can be easily extended to such projects. Different agile sub projects working together for a common goal can also be considered. Processes governing such projects with these features have to be comprehensively analyzed to be able to clearly distinguish the different supply chains and use the model described. This model is an example of how can such trends be identified in complex software projects and apply these quality assurance practices to improve the core processes.

663663