[IEEE 2006 13th Asia Pacific Software Engineering Conference (APSEC'06) - Bangalore, India (2006.12.6-2006.12.8)] 2006 13th Asia Pacific Software Engineering Conference (APSEC'06)

Cycle Time Reduction

Nagesh Mukundarao LogicaCMG Pvt Ltd, Bangalore.

E-mail: [email protected]

Abstract

In today’s competitive market, customer needs quick solutions with minimum cost, with out compromising the quality. Five years back, the average project cycle time was 4 to 6 months (was measured in months) and currently it is between 8 to 16 weeks (is measured in weeks). In near future, this will be measured in days. There is a need for quick decisions, earlier we used to say “no decision is better than a wrong decision”, but now it is “any decision is better than no decision”.

The Cycle Time Reduction (CTR) can only be possible by quick turn around in the project. This introduces challenges like running many activities in parallel (multiple critical paths). This implies increased risks in the project, increased stress on the project team, increased communication channels leading to complex communication issues, reduced time frame to adapt to the changes and many more. This in turn might impact on the company’s business in the longer run.

This paper provides a list of approaches practiced to achieve the challenge of reducing software project cycle time 1. Introduction

The cycle time is the time required to process a customer order, which might start with the customer phone call and end with the order being accepted. Cycle Time Reduction is identifying and eliminating the activities that do not add value to the product. Just-in-time (JIT) is one of the early outcomes of CTR effort and is defined as �a philosophy of

manufacturing, based on planned elimination of all waste and on continuous improvement of productivity� [13].

Customers generally evaluate a supplier�s performance on five factors: product performance, price, quality, delivery and responsiveness to the customers changing needs. In fact, flawless delivery and responsiveness can very often be the deciding factors in getting new customers and keeping old ones.

The market demands quick solutions and more focus on customer satisfaction. This puts the performing organizations in air-tight situations leading to more project failures, increased employee dissatisfaction and more employee turn around, increased recruitment and training costs, loss of business opportunities and increased distress in the employees leading to loss of life.

As leaders, our responsibility is to create the ventilations and put the teams in ease, convert the distress to eustress (positive energy) and make the teams flourish. Bring in the culture of chasing the change and quick adoption to the changes in the teams. During late 90�s the window to market was between 3 to 6 months (revenue realization of new ideas). Currently this is between 4 to 6 weeks, the ideas needs to be implemented quickly before the competition can pick up, capture the market and earn revenues out of it.

The figure 1 represents today�s scenario in projects, the scope remains constant and the pressure is to cut the cost and time. Many times customers are ready to bear the extra cost provided, the delivery can be made earlier with out compromising on the quality.

XIII ASIA PACIFIC SOFTWARE ENGINEERING CONFERENCE (APSEC'06)0-7695-2685-3/06 $20.00 © 2006

Figure 1. Cost and time relationship

If we can reduce the time by 20% by increasing the cost by 10-12%, customer is ready to bear the cost. This implies adding more resources to the project, having more parallel activities; this also means increased number of critical paths and risks in the project and no chance for making a mistake. This is the balance between cost and time, beyond certain point we can�t crash the activities unless we find out some innovative/automated methods to speed up the work.

2. Approaches used for cycle time reduction

Following are the few approaches used in the

projects to cut down the cycle time. 2.1 Prioritizing the requirements

The figure 2 below represents the relationship between frequency of use and the criticality of the requirements [15].

Figure 2. Requirement Categorization

The quadrant-1 represents the business critical requirements and most frequently used features. These are the mission critical features; Non availability of the feature in the product is not acceptable. For example, rating feature in a mobile application.

The quadrant-2 represents business critical features, but less frequently used once. The business can withstand the non availability of these features for a while (a day or two, sometimes until a week). For example, month end processing jobs.

The quadrant-3 represents frequently used features, but not critical to the business. For example display of caller identification number, location identification in a mobile.

The quadrant-4 represents less frequently used, low criticality features to the business. These are all nice to have features; non availability of these features will not impact the business.

It is a good practice to note down the criticality and the frequency against each requirement. This means the project can be delivered in phases and there is an opportunity for the early delivery of the required functionality to the customer.

Recommendation- Plan for frequent small wins: Many times customer gets the clarity and more ideas when they see their vision or dream getting realized in the form of product. Plan the first release of the product with bare minimum features (Must Have). The subsequent releases can be planned based on the priority of the features / defects in existing releases. This is a compromise between the features and the time lines for the upgrade; usually the upgrades are planned on a bi-weekly basis in a product scenario.

2.2 Planning

Everything should happen twice in project, once on paper or in mind (Plan) and other in reality (Execution). �If you fail to plan, you are planning for your failure�. The plans are dynamic in nature. Keep updating/changing the plan as the project progresses.

Recommendation - There should be a basic plan laid out at the beginning of the project and detailed execution plan needs to be worked out on weekly basis. The execution plan should be in line with the basic plan and this is required because at the beginning of the project, the plan has been built on the available


limited information, as the project matures, more clarity is obtained. The execution plan should be like who does what and when. We can use simple MS-Excel based tools to track the execution plan.

2.3 Use of lean and mean process in the project In software development, lean is about transforming

customer needs into deployed software rapidly, reliably, and repeatedly. Lean is not about slowing down and being careful, it's about catching errors the moment they occur so that you can reliably go fast [16].

The processes defined in the organization may not exactly suit your project needs. We need to understand what process might work for us based on the type of the project. (We can�t have every one wearing a white 42 size shirt; the shirt size should be based on the height and weight of the person.) Clearly state these process tailoring required for this project and get an approval from all stake holders.

For example our process recommends having quality gate/check point one for User Requirements Specifications (URS) and another for System Requirements Specification (SRS) phase in the project. In our project, we had the requirements detailed enough from customer and we skipped the SRS phase in the project. If we had included the SRS phase in the project, this would have added another 20 days of effort in the project and 8 days to cycle time.

Another example is in one of the project, we prepared 1200 page design document (because the process recommends for a low level design with using class diagrams, Object diagrams) along with a prototype, and produced the document for approval to customer. At the end of the project in the feed back customer said he was looking for a flow diagram than a big design document. We had spent 4 person months of effort to prepare the design document and if we would have understood the customer needs and tailored our process accordingly we would have saved 3 person months of effort and could have delivered the project at least 3 weeks ahead of schedule. �Only right kind and amount of spices (Processes) can bring good flavor and taste to the dish (Project) and achieve early delivery.�

The objective of the process should be - Remove unwanted actions / waste / over heads

- Enable capturing of defects in early phases of the project

- Design the process in such a way that it falls through the set of defined actions and make sure to close the feedback loop to arrest any gaps.

- Have right number of check points/ quality gates defined in a process. If the checkpoints defined are less than the required, then the defects seep through to the next phase of the project. If there are more than required this becomes a process over head.

- Plan for a group review of the deliverables wherever possible as this is more effective

- Achieve consistency in delivery Recommendation - Use the process tailoring

guidelines effectively to customize the process that is required by your project.

2.4 Customer Involvement Invite a customer representative (preferably an end

user) to work with the project team. This helps in two ways, the first is building a good relationship with the customer and secondly and most importantly it makes the customer feel part of the cohesive team [8]. It has also been observed that numbers of non conformities raised in these projects during the quality audit are very less. Customer could appreciate the amount of effort put in to the project and makes him feel the ownership of the product. In couple of projects this has been tried out and during implementation there was a discrepancy found in the product. The customer representative who worked with us went one step ahead convincing his users and made them accept the product.

At the beginning of the project, there is a huge gap in understanding the customer requirements by the performing organization. As the project progresses over the period of time, the understanding gap narrows down. This is illustrated in figure 3.


Figure 3. Gaps in understanding requirements [2]

After the time interval �T� in the project, �A� is the gap in the understanding of the requirement by customer and the performing organization. By involving the customer the gap will come down by �A-X� (the gap has reduced by �X� units) units. For example, in one of the project, a team went to customer site for requirements collection, while collecting the requirements the team also prepared the prototype and shared with the customer. The customer had approved the prototype. In case of any deviations or disagreements we always referred to the prototype for clarifications. This has enabled the team to deliver the product 2 weeks before the agreed date.

Recommendation - Many times the root causes for the delay boils down to requirements management. This is one of the major reasons why customers should be involved in the project. The Agile project management strongly recommends involvement of the customer or a proxy customer throughout the project life cycle.

2.5 Team Management

The first challenge in projects is meeting the agreed commitments, secondly there will be pressure to cut down the project cycle time. These challenges are not easy to achieve as, emotions/complications multiply, when the team is under pressure to meet the crunched deadlines. CTR also means early realization of revenues to the performing organization and to the customer. CTR is not limited to projects, it is about taking every opportunity in the project/organization to optimize time, it includes reduced training time with a steep learning curve, quick setting time, quick hire and

quick infrastructure set up, quick decisions and many more.

As per Tuckman model 1965, a group/team undergoes following five stages, Forming, Storming, Norming, Conforming and Performing. The couple of recommendations below helps us to reduce the time required to bring the team to Conforming and Performing stage and retain the team for a long duration in that stage. In big project, where project is running for more than 6 months, the cycle can repeat.

A team can only flourish if we as leaders can create the �chasing� attitude in each individual in the team and a supportive environment to achieve the same.

Try to bring one positive change in a month with each team member, you have won the battle.

Recommendations: - Make it very clear to the complete project team on

what pain problem we are solving for the customer in the project kickoff meeting. Then the team can appreciate the customer�s requirements and provide value added solutions to the problem.

- Meet every individual in the team formally on a fortnightly basis and record their aspirations. If required re-align their expectations towards the project goals.

- Take each opportunity to mix and talk to the team, for example join the team for lunch, take an opportunity to pick-up or drop your team member on your way to office or back home. This will enable informal communication channel and brings closeness with the team.

- Stay close to team during crisis. Make it a practice to leave the office along with the last person in the team.

- Allow the team members to do small mistakes because failure teaches more lessons than the success.

- Take the team for a walk after lunch; make them not to use the lift.

- Bring in the culture of responding positively to the changes in the project. Tune the team members in such a way that they can expect changes on a daily basis.

- Encourage team members to read and attend training on stress management, anger management, work-life balance and self management.

- Encourage team to take Corporate e-learning (on-line training) activities like, corporate finance etc., Put these activities as a part of the teams objective.


- Create trust-based and open communication channels in the project.

- Appreciate the team members for the work done, which acts as a booster to others.

- The last but not the least, do not hesitate to punish the team in case of failure to meet the project objectives. At the same time encourage them when they meet the deadline without compromising on the quality.

2.6 Risk and Issue Management

Many experienced project managers say 50% of the project management activity is Risk and Issue management. With authors experience it is true, maintain a detailed risk and issue register and track them closely (recommended twice a week). The figure 4 represents the lifecycle of the risk.

Figure 4. Risk life cycle

Risk is an event foreseen in future, a risk tracker

should have what, who, when, how (mitigation and contingency plans), probability of occurrence and impact. An issue tracker should have what, who, when and how parts of the issue.

Issue is the event happened in the project. Ideally these could have been captured in the project as risk. In reality it is not possible to capture all of them as risks, so the project expects these risks to be addressed fully when they are spiked out in project in the form of issues. Issues are like fire, and should be extinguished quickly, if not it may burn the complete organization.

If the project fails to address the risks in the form of issues, the intensity will increase and converted to crisis. If the crisis is not managed properly it becomes disaster ending in unpleasant circumstances (we may end up loosing the customer/business).

Recommendation -Carryout the risk identification exercise with the team members at least once a fortnight in the project. This will ensure not only safe mitigation / contingency plans and also facilitates smooth progress of the project.

Maintain �to do list�, preferably hand written. Keep looking at the list every hour and follow-up on the

actions closely. Author uses a simple action tracker as shown in table 1 below; this helps the author to be on the top of all the issues.

Table 1. To do list To do list

Sl # Description Status

1 Follow up on the design approval from Nick √

2 Raise HW request 3 Reply to Tom's mail on design date

4 Work on review comments from quality team on Project plan.

2.7 Metrics management

Metrics are reliable and most effective decision support system in the organization. It is important to identify the metrics to be used in the project at the beginning based on objectives of the project, size, complexity, nature and importance of the project. The metrics indicates the organization�s Project management process maturity level [4].

The project looks very dirty if it has lots of data, risks and issues; but in reality these are the healthiest projects in the organization. The objective of measurement is to allow the managers and practitioners to make data-driven decisions on time, to track organization�s progress towards goals. Measurement increases the chances of project success. Measurement happens through out the life cycle of the project. Do not hesitate to introduce new measurements at any stage of the project, if there is a need for it.

Measurement brings in predictability; without measurement project management becomes an issue management. It is like spikes on a water balloon. The general tendency is that whenever the spike appears in the project, the team jumps on it and due to the whole team concentrating on one issue, the current issue subsides and some other issue spikes out somewhere else in the project. This is a reactive approach and is called �Water balloon Approach to project Management�.

Recommendation -It is good if we can use following few metrics in the project to achieve predictability, better risk and issue management, better decision making, better control, consistency in delivery and in customer delight.


2.7.1 Indexes: An Index is the ratio of planned data to the actual data [14]. A value greater than 1 indicates the project is performing better than plan and a value less than 1 indicates the project is behind the plan. The most commonly used once are Schedule Index, Effort Index, Budget Index, HR Index, Test Index and Resource Index. These indexes can be collected over a period of time and plotted in the form of control charts.

For example Schedule Index=1.1, Effort Index=0.9, Cost Index=1.02 and Resource Index = 0.95 indicates ahead of schedule, consumed more effort, with in budget and using resources more than planned. Author would categorize the project as �Green�. A quick inference from this is that the team stretched the days and met the defined goals.

2.7.2 What is remaining?: This is already reported by many, that this is a visionary process; it is a normal practice to track what is completed and always miss out what is remaining in the project. As you progress you always have an eye on what is remaining in terms of Schedule, effort, Budget, Resource availability, deliverables etc.

2.7.3 Variance Analysis: It is the comparison of actual performance with the planned performance [1]. Usually these are computed as percentages. This is (((Plan � Actual)/Plan)*100), Negative indicates behind plan and positive indicates ahead of plan. This can be applied to Schedule, Effort, Cost, number of test cases, Review defects, Test defects, HR and Code.

2.7.4 List of Deliverables and Review analysis: It is a good practice to capture deliverable ID, name, pages produced, defects, status, review time, re-work time, originator, reviewer, approver, due date and owner and the delivery date [14]. Extending this to code will help tracking the progress of the coding and to capture the coding defects and review effectiveness and efficiency metrics.

2.7.5 Test data analysis: Capture the number of test cases planned, executed, defects captured and the severities in the project at various phases like Unit Testing, Integration Testing, System Testing and Customer Acceptance Testing [14].

2.7.6 Earned Value Analysis: This is the most recommended way of measuring the progress of the project by PMI [1]. This can only be used if you have the complete budget/actual details. This provides the complete picture of the project in terms of cost.

2.7.7 Customer complaints and recommendations: Usually the customer satisfaction surveys are carried out at the end of the project or at the end of a quarter, which ever happens earlier. Take immediate actions on the customer comments and drive them to closure. Inform the customer what actions have been taken and when he/she can expect the resolution [7].

2.7.8 HW and SW Resource: This is mostly used in large projects which require more number of HW, SW resources. It is expected to track the HW/SW resource, Licenses, expiry dates [14].

2.7.9 Change Requests (CR): Keep track of the CR�s, the impacts on scope, budget, time and quality with approval details [1].

2.7.10 Action Item Tracker: This is again used in the big projects to track the actions. The action tracker will have what, who, when and how parts to it. The issue tracker can be extended to track the actions in the project [14].

2.8 Automation tools

In today�s organization it is recommended to use automated tools. Statistics show that using automation in projects can save up to 80% of the efforts. In product business you can�t be competitive if you are not using Reusable components, automated Builds and automated testing tools. There are lots of off-the-shelf automated tools available in the market; you can choose them based on the need and the available budget [16].

Recommendation - During free time, encourage team members to identify and develop small tools which can be used in the project.

In one of author�s project, the team developed a tool to test the API�s (Application Program Interfaces). To about 80 API�s manually use to take about 3 days of effort, using tool this can be performed in 3-4 hours.

2.9 Project Database

We can�t afford to learn from our own

mistakes/failures, it is very expensive. We should also learn from others mistakes, lessons learnt and good practices followed in previous projects often adds


value to CTR. Refer to the project database for risks, issues faced, tools used, lessons learnt and you can always get in touch with the people who have worked in that project to understand more on the project [1].

In our division, based on the previous projects data, we have come up with an estimation formula; given the Coding and Unit Testing (CUT) effort we can compute the complete project effort, defect density, peak time size, approximate project duration and number of test cases and system testing rounds required. Every six month once the project data is analyzed, the formula is re calibrated. This has improved the accuracy of the estimations and reduced the time required for estimating the project efforts.

Recommendation - Data analysis surfaces many hidden facts. At the organizational level, use statistical prediction models generated from historical data to predict the estimates, defects, duration, size, etc,.

2.10 Use of expert services

In a given project you may not have the expertise to carry out the work. It may be useful to subcontract part of the work to an expert in the market or look for the off-the-shelf products in the market. This is one of the risk transfer strategies in the project [16].

There is no point in spending time in improving on the weakness; instead it is worth spending time to buildup on the core strength, which can show tremendous results. This is applicable to an individual and to an organization.

For example our division has expertise in building server side components of a telecom billing solution, we also have a small client application, when we did a make or buy analysis it has been realized it is better to sub-contract this piece of work, the reasons being

- No expertise available in this technology - If we hire the team, after the project is complete

what will we do with the team? - Other overheads of managing the development and

maintenance of the product

Recommendation - Identify the core strength of the organization / division and take up the work in the related area. The other part of the work can always be outsourced to an expert in that respective area with in / outside the organization.

3. Conclusion

CTR is about reducing time required from converting the customer order in to delivery/acceptance of the product. It doesn�t need high investments; it is about intelligently identifying and eliminating the waste in the project. The simple approaches listed in this paper have provided significant benefit in delivering the high quality product few days earlier or on time, and achieving the great customer satisfaction (a satisfaction rating > 4.25 on a scale of 1 to 5, 1 being the lowest and 5 being the highest). The flawless delivery and responsiveness can very often be the difference in getting new customers and retaining old ones. In recent, we have delivered high quality product on time to the customer, the customer has awarded a follow-on business worth of 48 million Indian Rupees.

4. References [1] A Guide to the Project Management Body of Knowledge (PMBOK® Guide), PMI, USA 2003

[2] CSQA Study guide, QAI USA, 2003

[3] Roger S. Pressman, Software engineering � A practitioner�s approach, Mc Grew Hill, USA, 2004

[4] Robert T.Futrell, Donald F.Shafer and Linda I.Shafer, Quality software project management, Mc Grew Hill, USA, 2004

[5] Rita Mulcahy, Risk Management: Tricks of the Trade for Project Managers, PMI, USA, 2004

[6] Thomas R Black, J Davidson Frame, The project office, Crisp Publications, USA, 2004

[7] Richard F Gerson, Measuring Customer Satisfaction, Crisp Publications, USA, 2004

[8] Craig Larman, Agile and Iterative development, A managers Guide, USA, 2004

[9] Kent Beck, Extreme Programming Explained, 2002

[10] Larry Bossidy and Ram Charan, Execution - The discipline of getting things done, 2002

[11] Dayle M. Smith, The eleven keys to leadership, 2004

[12] Dr. APJ Kalam with Arun Tiwari, Wings of fire, 2005

[13] Jeffrey K Liker, The Toyota Way � 14 management principles from the world�s greatest manufacturer, 2004


[14] Nagesh M, �Quantitative project management�, PMIPCC Asia Pacific Conference, Hyderabad, April 15-17, 2005.

[15] K.Wiegers, First Things First: Prioritizing Requirements, Software Development, vol-7, Sep- 1999.

[16] Ian SommerVille, "Software Engineering" Seventh Edition, ISBN:0-321-21026-3, 2004, Addison Wesley


Documents

[IEEE 2006 13th Asia Pacific Software Engineering Conference (APSEC'06) - Bangalore, India (2006.12.6-2006.12.8)] 2006 13th Asia Pacific Software Engineering Conference (APSEC'06)