A Software Project's Cycle Time: ‘Are We There Yet?’

	Bookmark This Page Email This Page Format for Printing Cite This Article Submit an Article Read More Articles
	Related Tools & Articles Core Set of Effectiveness Metrics for Software and IT Automating Input Data to Improve On-Time Deliveries Software Development Convergence: Six Sigma-Lean-Agile
	Discussion Forum "I'm an industrial engineer and Six Sigma Green Belt....Can anyone please send me web links for information or information regarding how should I go about applying Six Sigma to the software industry?" Contribute to this Discussion

Download Products CSSBB Preparation Pack - 2009 Version Design For Six Sigma (DFSS) E-Book or Print Project Selection Process Pack

By Gary A. Gack

Software project managers, who are responsible for shepherding software projects to completion, often feel like they are on a cross-country trip with several youngsters in the back seat. It seems like every few minutes someone asks, "Are we there yet?"

Cycle time for a software project is usually understood to mean the elapsed calendar time between official project start (problem statement and scope is agreed upon, and staff is assigned) and the time the resulting software system is operationally available to the customer (tested, documented, installed, trained and supported). In other words, cycle time is the elapsed calendar duration required to fully deliver an agreed-on amount of functionality.

What Drives Cycle Time?

Primary factors that drive cycle time include:

Amount of functionality to be delivered - The "size" can be measured in function points, story points, use cases, lines of code or whatever. Note that any discussion of cycle time improvement is meaningless absent the "how much" (size) dimension – it is trivially obvious that we can deliver faster if we deliver less.

The delivered quality requirements - Clearly a software company can deliver anything more quickly if it does not need to work when delivered. Hence, a meaningful measurement of cycle time improvement needs to consider some measure of delivered quality, such as defects per size or defect containment effectiveness.

Time on task - This is the extent to which the project team is actually devoting time to the project of interest. Rarely is it 100 percent. Most teams will spend a certain amount of time fixing defects related to a prior release, working on other parallel projects, attending training, taking vacations, etc. Interruptions are a fact of life and have a profound, but usually unmeasured, impact on both cycle time and productivity. Every interruption requires a "context switch," i.e., absorbing the particulars related to the cause of the interruption, such as understanding the specifics of a prior release defect report, investigating potential causes, determining potential solutions, implementing and testing fixes.

(The nature of most software work involves a significant amount of complexity. Software developers must marshal many facts about logic flows, data structures, business rules and other considerations in their conscious memory in order to determine the proper course of action. Immersion in the necessary details often takes hours or days, and sometimes weeks. Worse, upon return to the original project problem, they must repeat the same sort of immersion in the relevant facts and data. Some studies suggest that this context switching can absorb up to 50 percent of total effort when interruptions are frequent, as often they are. Hence, one key to improving cycle time is reducing interruptions that require context switching.)

Defect insertion rate - This is largely a function of the experience level of the assigned personnel, the complexity of the problem being addressed and the reasonableness of the established schedule. As all industry cost-estimating models clearly demonstrate, excessive schedule pressure leads to significantly higher defect insertion rates, and hence higher rework.

Appraisal methods and timing - The type and amount of appraisal (reviews, inspections, testing) done at each phase of the development process (requirements, design, construction) has a profound influence on the effort required to find and fix defects. Failure to do sufficient early appraisal leads to significantly increased effort in appraisal (defect-finding) and rework (defect-fixing). More effort spent on finding and fixing defects invariably leads to longer cycle times.

Hand-offs and queues - Lean thinking has clearly shown that that both hand-offs and batch queues contribute to increases in cycle time. Smaller batches (functional scope) and end-to-end team responsibility contribute positively to reduced cycle time.

How Can Cycle Time Be Reduced?

In the near term, most organizations can realize meaningful cycle time reductions by adopting Agile methods. Agile reduces cycle time in many situations because:

• Smaller teams undertake smaller units of work and are hence more efficient.
• Smaller iterations facilitate parallelism. Iteration A can be tested while Iteration B is being built and Iteration C is being defined (requirements are being determined).
• Smaller units of functionality are less complex, and defect insertion rates are consequently lower.
• Shorter iterations reduce the consequences of requirements changes driven by changing business circumstances.
• Most Agile teams are structured so that they have end-to-end responsibility – hence fewer hand-offs and shorter queues or backlogs of incomplete work.
• It may, in some instances, be less difficult to manage and reduce interruptions.

In the longer term, it remains important to address and measure all of the factors that contribute to longer cycle times. Agile methods can reduce, but do not eliminate, root causes of cycle time problems. Lean Six Sigma drives to root-cause solutions.

Certainly cycle time is an important Y (outcome metric), but so is efficiency, which might be defined as cost (effort) per unit of functionality delivered (size). Ultimately, cycle time and efficiency are intimately connected. Optimizing one without regard to the other is certainly false economy. If shorter cycle time leads to lower throughput (cumulative functionality delivered), the gain can easily be an illusion. In some circumstances that can occur as a consequence of testing overhead associated with subsequent iterations, especially when there are many inter-dependencies with other systems. Even when cycle time is the primary metric of effectiveness (the primary CTQ, or critical-to-quality element), productivity will always be an important secondary metric. No matter how it is sliced, efficiency will always constrain cycle time.

About the Author: Gary A. Gack is a founding partner of Six Sigma Advantage, based in Rockland, Massachusetts, USA. He has an MBA from the Wharton School, is an ASQ-certified software quality engineer and a Six Sigma Black Belt. During his 40-year career in the software and IT industry, he has managed a variety of large-scale software projects and has consulted with dozens of Fortune 1000 firms. Mr. Gack co-authored Six Sigma Advantage's Black Belt, Green Belt and foundation curriculum. He can be reached at ggack@sixsigma-advantage.com.

BEST SELLING PRODUCTS (iSixSigma Publications) Six Sigma Black Belt (DMAIC) Training Slides - 2009 Version! The 2009 Six Sigma Black Belt course includes over 40 more slides than the 2008 version. Contents include: 1,220 PowerPo... Certified Lean Six Sigma Black Belt Assessment Exam Interested in assessing your knowledge of Lean Six Sigma? Preparing for certifications? Testing your students and traine... Certified Lean Six Sigma Green Belt Assessment Exam This assessment exam is useful for students interested in assessing their knowledge of Lean Six Sigma on the Green Belt ... Kaizen Workshop E-book This 150+ page ebook teaches key tools and techniques of Kaizen, as well as real application to enhance learning. Kaizen... Design For Six Sigma (DFSS) E-Book or Print Need an "encyclopedia" consisting of many of the tools you’ll study? Need a helpful refresher to apply the DFSS process?... Certified Lean Six Sigma Black Belt E-book In 670 pages learn everything within the Lean Six Sigma DMAIC body of knowledge to successfully achieve Black Belt certi... Six Sigma Yellow Belt Training Slides - 2009 Version The 2009 Six Sigma Yellow Belt course is comprised of: 503 slidesInstructor notesSlide explanations15 data sets19 suppo... Sell Your Products