Samuel Prasad, Ph.D.

PMBOK and Scrum are like oil and water? I don't think so..

Project management methodologies based on PMBOK and Scrum have more in common than they are different, which is contradictory to the wide-spread belief that the two don't mix. They are very much the same except for one key difference. Well, both PMBOK and Scrum are controlled by the triple constraints of cost, schedule, and scope. So where’s the difference?
The difference is:  in PMBOK the scope is locked down so that the project schedule and cost can be estimated.
Scrum, on the other hand, embraces scope changes. So it only follows that no attempts are made to lock down scope. Instead Scrum promotes the approach where schedule or cost or both are locked down. This allows the scope or product feature set to be modified as necessary with a view to delivering maximum value to the user in a short period of time. This, of course, implies that Scrum projects, in most cases, are in a perpetual releasable state.

The traditional PMBOK plan-driven approach follows the PDCA (plan-do-check-act) cycle made popular by Dr. W. Edwards Deming, who is considered by many to be the father of modern quality control applies to both PMBOK and Scrum projects.
The following figure illustrates the PDCA cycle in a traditional PMBOK setting.

  

• Plan. Define the project objectives. Understand the requirements. Plan for implementation and delivery.
• Do. Execute the plan in incremental steps. A step may last a few weeks or months at the end of which there are artifacts, including partial system functions, that are made available for review.
• Check. Review the results of the plan execution. Test and analyze the results, identify what worked and what did not.
• Act. Modify the plan based on lessons learned in the "check" step: Go through the cycle again with the new plan to prevent defects in the previous iteration from occurring again.

The following figure illustrates the PDCA cycle in an Agile (Scrum) setting.

 
 

• Plan. Define the project objectives. Understand the requirements. Generate a list of product features called the product backlog. Prioritize the items in the product backlog in concert with users and business stakeholders taking into account the usefulness of a product feature and its associated cost. Create a plan for implementing the backlog items in order of priority. Break up the plan into incremental steps (or Scrums) and identify the backlog items to be implemented in every Scrum.
• Do. Execute the plan. Implement the items that are part of the Scrum.  A scrum typically lasts anywhere from 2-weeks to a month. At the end of the scrum, the product features are fully functional. They have been tested and the results validated as part of the Scrum.
• Check. Review the results of the plan (Scrum) execution. Test, analyze the results and identify what worked and what did not.
• Act. Take action based on lessons learned in the "check" step: Go through the cycle again with a modified plan. In other words, if the product backlog needs to be modified and the items re-prioritized, please go back to step 1 and do so.  Repeat the steps. 


Moving from PMBOK to Agile (or points in-between)
A PMBOK manager who is used to the traditional "command and control" approach must learn to lead from behind (see my blog on leadership styles).  Learn to hand control over to the team. Learn how to ask the right questions at the right time in order to provide guidance and direction to the team. Keep in mind that the manager (or Scrum Master) still makes the final decision and is responsible for the outcome of the decision, but this style recognizes the strength and knowledge of the team and is a sign that the manager is secure, confident and is not afraid to seek counsel from the team. This obviously is a style that most team members respect. One other thing: make sure that the manager knows, understands and believes in the Scrum process. This is important not only to motivate and mentor the team but also is critical to the successful completion of the project.

Good luck on your journey from PMBOK to Scrum or to any points in-between.

It's the Data, Stupid! Why data is an organization's most important asset.

In the beginning there was the ODS or operational data store - typically a collection of tables in a relational database. The ODS contained the company's raw data which was used to run historical reports on past transactions. Then came the data marts (DM) essentially a snapshot of the ODS. The BI Analysts who were highly skilled statisticians and mathematicians ran queries against the DM, extracted data from the DM and performed their analyses. But all the analyses in the world could not deliver critical information in a timely manner to help management make better operational decisions to improve customer service and help the bottom line.

The good news is that DMs and Business Intelligence (BI) have evolved significantly over the past decade. It is no longer acceptable to have DMs that are just time-stamped snapshots of the ODS. The raw data in the ODS has to be cleansed, massaged and distilled...and I mean distilled...into useful information stored in formats like, cubes, dimensional entities and aggregates in columnar structures at various levels of granularity and recency so that the analysts can visualize, manipulate and study the data from different angles.

What has changed in BI in the past decade?

Data Frequency - real-time or close to real-time
Daily or weekly snapshots of the ODS are no longer acceptable for making decisions. This means that we need to have intra-day data marts as close to real-time as possible that contain only a subset of data that renders recent customer transactions and activities very quickly. Intra-day snapshots of data are trickle fed through data filters into real-time data marts, allowing operational personnel the ability to analyze events occurring during the day of the event. As you can imagine, this means that the volume of data being stored increases substantially. The main ODS and OLAP data mart now contain tens of terabytes to hundreds of terabytes (even petabytes!) to support all forms of BI now. And it should be noted that the granularity of the data for operational BI must be at the lowest level of detail. All this means that, not only does the ODS and OLAP DM infrastructure have to handle faster, more frequent loads of data, but seamless scalability is mandatory – whether it is for storing and processing increased volumes of data, or maintaining the integrity of the environment (backups, failovers, etc.)

Performance - instant gratification
While performance in traditional BI environments has always been important, it is now critical that responses to queries against the intra-day real-time data mart be almost instantaneous. In many instances, requests originate from and responses are received on handheld wireless devices. Communication is no longer one-way. In other words, users are able to send back comments and feedback which contain valuable information (unfortunately in unstructured textual format in many instances) that must be captured, parsed, stored and fed into the ETL process. Add to this the fact that the environment must still support traditional BI users. A mixed environment with ODS, the traditional data mart (OLAP) and the real-time data mart means the software must have the ability to prioritize and route queries, not only according to their importance to the enterprise but also based on data and response requirements.

Number of users - scalability
There was a time when Business Intelligence was the domain of only statisticians and mathematicians who extracted data from historical snapshots of the ODS to perform their magic. Gone are those days. Now BI and analytics are used by business users and even customers want to get into the act since they want access to their transaction history and past experiences at a particular store or web site. Here's another catch. Not all users are human. There are web-bots that roam in and around the data marts trying to detect patterns, do simulations and project outcomes. All of this puts a tremendous strain on the network, server and infrastructure that must be horizontally and vertically scalable to support the onslaught of requests, queries and analytics being thrown at them.

Unstructured Data - Facebook, YouTube, blogs and other social media
Unstructured data is increasingly being used to make critical decisions. The ETL process has to be retooled to handle different forms of textual, audio and video data. The technical challenges that this poses are quite steep since most BI environments are just not set up to handle unstructured data. The space requirements of the ODS and data marts are expected to grow exponentially  because of this; processing capabilities required to parse and convert unstructured data into a structured format puts a tremendous strain on the processing and infrastructure requirements, which in turn has a direct impact on scalability and performance.

The following diagram illustrates a typical BI system of today.

  
 

While the "Daily ETL" process takes in data from all data sources to perform incremental updates on the ODS and OLAP data mart, the "Real-time ETL" also called an intra-day ETL accepts transactions through a filter configured to feed only transactions that are deemed to meet the "recency" criterion. This essentially limits the data to transactions and customer behavior that are needed to make decisions based on events occuring during the day. Unstructured data coming back from a customer's handheld device is staged in a daily customer tracking DB and fed into the "Daily ETL" process along with data from all the regular data sources. It is also fed into the "Real-time ETL" process so that it is immediately available in the Real-time data mart.

Data marts and BI systems of the future must be completely rules-meta-data-driven capable of self-learning and able to modify their behavior based on usage and data types that are yet unknown.

Future of BI Analytics

The future of Business Intelligence (BI) Analytics rests on emerging technologies that will use special hardware appliances that will effectively mine data at tremendous speeds and perform predictive analysis and extrapolate trends using simulation in real-time. Traditional BI products, including dashboards and ad hoc queries use historical data to generate reports, which only tell the story of what happened in the past. In future, predictive analytics, alerts and extrapolation of trends will become common practice through the real-time exploitation of informational patterns hidden in historical data to project what might happen.

Hardware appliances like IBM's Neteeza and Oracle's Exadata provide extreme performance in both OLTP and OLAP models, allowing for very quick deep dives into the data specifically in the latter environment. These appliances are effectively supercomputers that can chew through large volumes of data very quickly.

In addition, the increasing popularity of columnar databases like Sybase IQ, HP Vertica and ParAccel allow data mining software to access a specific type of data or fact based on an attribute or dimension must faster than traditional row-based databases because in a columnar database, each data page is populated with data from only one column. 

Tom Davenport and Jeanne Harris in their book "Competing on Analytics" postulate that in the future more automated decisions using "operational business intelligence" will be made by machines rather than relying on humans. It will no longer be acceptable for companies to wait days or weeks to extract data from transactional OLTP systems, load it into data marts and then run historical reports through queries. There will be more prediction and less reporting. There will be greater use of alerts to notify managers immediately when key indicators are at undesirable levels.

Another area of data mining that is almost non-existent toady is the mining of unstructured or textual data. With the ever increasing popularity of social media there is an urgent need to develop efficient parsers to analyze unstructured textual data and transform them into information that can be used in predictive algorithms to project future behavior.

Many of the above changes will hopefully be driven by companies who want to be at the top of their game and increase customer satisfaction. Ultimately the companies with the best analytics will have the most efficient marketing campaigns and promotions.  Their customer service will be the envy of their competitors. They will use just-in-time inventory and employ the best people in the industry compensated directly based on their contributions to the company. They will be the leaders who will outperform their competitors and lead us into the future.

Business Intelligence needs better analytics

In recent years many companies have jumped on the "business intelligence" (BI) bandwagon. What is BI? With access to vast amounts of data, BI is definitely not just a collection of reports generated from historical data. BI is also not software that can generate flashy-looking dashboards that provide readings of current key-performance-indicators but provide no actual intelligence based on extrapolations of past events. The net result is that many companies caught up in the BI hype have been quite disappointed in the return on their investment. To put it bluntly, BI with no predictive analytic capabilites to help organizations achieve high performance capabilities is pretty much useless.

In a series of studies conducted by Accenture, Jeanne Harris proposes a five-step model called DELTA  - data, enterprise, leadership, targets and analysts.

DATA - no two companies have exactly the same data even though they may be in the same industry. Mine the data to find what is unique about your company. Use the uniqueness to gain an analytical edge. To succeed in analytics, start identifying the data that you alone possess and recognize the value in it.

ENTERPRISE - data cannot live in silos. Integration of data, processes and analyses in a large, geographically dispersed company is a challenge in itself. So, does it make sense to adopt a companywide perspective for analytics? It depends...especially if all departments in the corporation share markets. According to Harris answers to the following six questions help determine if a companywide approach to analytics will be helpful.
 
Source: Davenport, Harris, Morison. Analytics at Work: Smarter Decisions, Better Results. Boston. Harvard University Press, 2010

Bottom line -  a company that is committed to increasing customer satisfaction will ensure that its data does not reside in silos but is accessible with integrated analytics across the enterprise; the only exception being if data has to be "siloed" for legal reasons.

LEADERSHIP - a company needs analytical leaders - individuals with people skills and an analytical bent. People who know to ask the right questions and will not hesitate to push back when the team makes recommendations based on intuition and not based on hard empirical evidence. Leaders hire smart people, mentor and train them.

TARGETS - Analytics should be targeted at areas where the ROI is the highest and can be easily measured. Some examples are:
analytics that enable effective use of resource sharing;

• analytics that increase customer satisfaction;
• analytics that increase profitability;
• analytics that increase quality;
• analytics that identify dependencies and streamline processes.

ANALYSTS - we need analytical professionals who understand statistical models, probability theory, trend analysis, classification algorithms and simulation. These jobs tend to require an advanced degree in mathematics, statistics and in a quantitative field.

Adopting the DELTA model can go a long way in building a strong analytical capability. However an aggressive implementation of DELTA can also result in stagnation and paralysis if we don't stay away from the following traps. Do not over-fit the curve, says, Kishore Swaminathan, a Beijing-based analyst because there is no sense in analyzing additional data once a pattern has been found. It also does not make sense to wait for data that simply does not exist. Design models and experiments based on the data you have, not based on the data that you would like to have. Lastly, it is important to know the risk tolerance of your company. Do not wait to act unless there is enough data to guarantee a successful outcome.

Business Intelligence when used right will result in an enterprise that is able to make its decisions in a timely fashion based on observations produced by empirical analysis of data.

Lean Six Sigma in Software Development.

"Six Sigma" is a process man-agement strategy developed by Motorola in 1986 to improve the quality of products by identifying and removing the causes of defects (errors) and minimizing variability in manufacturing outputs. "Lean" on the other hand is a production practice that aims to eliminate expenses for resources that are not creating value in the product.

How do we combine Lean and Software especially since Lean Six Sigma has had its origins in manufacturing and does not translate easily to software development? The Poppendiecks in their book titled "Implementing Lean Software development" successfully make a case that writing software is really a form of product development and hence the implementation of Lean Six Sigma in software development is possible. They claim that, software not devel-oped as a stand-alone product is usually embedded in hardware, or it may be part of a game, or a business process - which means that software is either a product or a subset of a product.

"The seven principles" of Lean Software Development are:

• Eliminate Waste
• Build Quality In
• Create Knowledge
• Defer Commitment
• Deliver Fast
• Respect People
• Optimize the Whole

Eliminate Waste
Identify the 20% of product features that deliver 80% of value to the customer. Focus on implementing the 20% for deployment in the first phase.

Build Quality In
Develop QA standards and QC processes to catch defects early on in the software development life cycle. Test-driven design (TDD) is a very effective to reduce and eliminate defects.

Create Knowledge
Use feedback from daily builds and early release of the minimum 20% feature set to customers for evaluation and feedback.

Defer Commitment
Define the architecture model such that most decisions related to the feature set can be reversed and changed. A realistic design approach is to leave options open so that irreversible decisions can be made as late as possible.

Deliver Fast
Deliver software so quickly that customers don't have time to change their mind", say the Poppendiecks.

Respect People
Allow team members to offer feedback and ask questions. Just make sure you answer every question. You are not too busy and neither is any question unimportant that it does not deserver an answer. Employ team-building activities to help open the lines of communication and create co-dependence between members of the team.

Optimize the Whole
Lean software development needs the support of the entire organization. The entire value stream from the time a customer request comes in, to the time the software is delivered must be optimized.

Software Quality Metrics

The indicators used to measure software quality are usually classified into two groups - end-product quality metrics and in-process quality metrics. The study of the relationship between in-process and end-product quality metrics is the main focus of software quality engineering. It is not surprising that results of numerous studies conducted at Motorola and IBM have found that improvements in in-process quality almost always translate to an increase in end-product quality.

END-PRODUCT QUALITY
End-Product Quality metrics consist of:

• Defect density
• Mean time to failure
• Customer problems
• Customer satisfaction

Defect density is a measure of the number of defects relative to the size of software, which is a function of the number of lines of code (LOC). The standard definition of LOC used in software engineering is any line of program text that is not a comment or blank line, regardless of the number of statements or fragments of statements on the line.

A simplistic definition of defect density is the number of defects discovered over a specific period of time divided by the size of software expressed in thousands of lines of code (KLOC).

The mean time to failure (MTTF) is defined as how long the software can run before it encounters a "crash".

Defect density and MTTF are correlated - a software program with higher number of defects is likely to crash more often than a software program with a lower defect density. It is important that defects (or bugs) that are associated with a low MTTF are identified and removed early. The defect density is also important for another reason because it is used as one of the factors in computing the cost and resource estimates of the maintenance phase of the software life cycle.

Customer problems - while defect density and MTTF are useful to drive quality improvement from the development engineer's point of view, it is equally important to consider the customer's perspective. All problems reported by the customer - not just valid defects - are counted as customer problems. Usability problems, unclear documentation, and duplicates of valid defects (i.e., defects reported by customers for which fixes or work-around solutions are available, but the current customers are unaware of them) make up the problem space from the customer's perspective. This metric is expressed in terms of Problems per User Month (PUM), which is the total number of customer problems reported in a specific time period divided by the number of users divided by the number of months in the reporting time-period. PUM is usually calculated every month after the software is released to arrive at a yearly average.

To reduce the value of PUM:

• Reduce defect density and increase MTTF.
• Improve usability.
• Provide clear documentation.
• Improve customer training and support.

The fourth metric - customer satisfaction - is measured by customer survey data via a typical 5-point scale:

• Very satisfied
• Satisfied
• Neutral
• Dissatisfied
• Very dissatisfied

Based on the 5-point scale several types of analysis can be conducted using:

• Percent of completely satisfied customers (Very satisfied)
• Percent of satisfied customers (Very satisfied and satisfied)
• Percent of dissatisfied customers (dissatisfied and Very dissatisfied)
• Percent of unsatisfied customers (neutral, dissatisfied and very dissatisfied)

IN-PROCESS QUALITY
In-Process Quality metrics are less formally defined and varies depending on the make-up of the software engineering team - higher the skill level and domain knowledge of the team, less is the use of in-process quality metrics. However, the goal is to learn how to engineer quality into the process so that the end-product quality is consistently high.

In most cases, in-process quality metrics means the detection and tracking of defects (bugs) during software testing. This is costly and not very effective in increasing end-product quality. However, there are several organizations with well-established mature processes where inspections are conducted at every phase of the software development life-cycle (SDLC) not just during the testing phase.  A defect that is detected at a later phase is much more expensive to fix than if it was either prevented or detected and fixed in an earlier phase of the SDLC. Inspections are carried out to specifically identify defects in architecture, interfaces, logic, and documentation at every phase - inception, elaboration, construction and testing - of the SDLC by reviewing the high-level design, low-level design, code and documentation.

All the new studies, once again, prove the old adage to be true - quality cannot be inspected into a product!

To steer a boat you have to move to the back.

This is quite contrary to the theories developed by Kurt Lewin, Ronald Lipitt, and Ralph White in 1939 which state that there are only three major styles of leadership:

• Authoritarian
• Participative
• Delegative

Authoritarian style of leadership assumes that the leader has all the information necessary to make the right decisions. For this style of leadership to succeed employees must unconditionally accept the power of the leader and follow directions without questioning them. It does not mean that the leader can use demeaning language, engage in abusive or unprofessional behavior. As you can well imagine, this style of leadership may work well in the military but it rarely achieves the desired goals in a non-military work setting. Why? People don't like to be ordered to do things without explaining the rationale for the directives and without a clear understanding of the end goals. 

The participative style of leadership is much more common in companies where the leader includes one or more employees in the decision making process. The leader still makes the final decision and is responsible for the outcome of the decision. This style recognizes the strength and knowledge of key employees and is a sign that the leader is secure, confident and is not afraid to seek counsel from others. This is a style that most employees respect.

The delegative style of leadership must be used wisely and only if the leader has the full trust and confidence of peers and the team. This style of leadership assumes that the employees empowered to make decisions understand the end goals, are able to obtain and analyze the required information before taking any action. This style must be used only if the leader is not quick to blame others even if decisions made by employees causes things to go terribly wrong.

Social scientists over the past century have come up with many leadership theories. Most well known among them are:

1. "Great Man" theories assume that leaders are born, not made.
2. “Trait” theories assume great leaders share particular traits that make them well suited for leadership.
3. “Contingency” theories purports that environmental and external variables, including the type of followers determine the person best suited to lead.
4. “Situational” theories states that people who can recognize situational variables that affect the outcome of an action or decision are best suited to be leaders.
5. “Behavioral” theories are based on the supposition that great leaders are made not born which is the exact opposite of the "Great Man" theories.
6. “Participative” theories suggest that good leaders elicit input from other members of the group before making decisions.
7. Management theories also known as "Transactional theories" are based on a system of rewards and penalties. Good leadership is rewarded for accomplishing the stated end goals while failure to meet them are seen as signs of poor leadership and are punished.
8. Relationship theories also known as "Transformational theories" is the best form of leadership where leaders are able to motivate, transform and inspire their group members. It is no wonder that leaders who belong to this group have the highest ethical and moral standards.


Transformational leaders are ones who have learned the art of leading from behind. They listen to the people around them. They usually surrounded themselves with smart problem-solvers who do not need to be told what to do. Transformational leaders spend their time focusing on what they should be doing to achieve the end goals because they know that the people around them will do the same without  having to be micromanaged or told what to do every step of the way.

"To steer a boat you have to move to the back. Leadership is about asking questions and letting people answer them," says Anne Berkowitch co-founder of SelectMinds a social networking company in New York.

Know the ROI of your project before you start!

ROI - Return on Investment - is a performance measure used to evaluate the efficiency of an investment. In other words, ROI helps in determining the extent of cost savings that are realized in return for use of a specific amount of money on a project. The Project Management Book of Knowledge (PMBOK) states that the project charter - a document that formally authorizes a project - must clearly state the business justification for the project including return on investment. In many companies the CFO or COO requires ROI to be presented before funding is approved for a project. The task of calculating ROI is not always easy because the cost savings of implementing a project cannot always be quantified in dollars. In many cases the benefits are intangible and non-financial as in providing a competitive advantage in the marketplace or delivering superior customer service.

It is especially important to know the ROI of a project in these times of shrinking IT budgets where many organizations are expected to deliver more services with fewer resources. Without knowing the ROI it is impossible to determine if a project was successful in meeting the business expectations of delivering increased revenues and/or reduced costs. Technology executives must be extra diligent in the ROI analysis of their projects because according to a report by the Standish Report, only 32 percent of IT projects were delivered on time, within budget and with the required functionality.  Forty-four percent were delivered late, went over budget or did not meet specifications. The remaining 24% were cancelled due to unspecified reasons.

It is a good idea to follow the PMBOK rule where ROI is calculated and included as part of a project's charter document even before the project starts. This clearly establishes ahead of time any project expectations of increased revenues or other intangible benefits if the project were to be delivered on time and according to specifications. It is however not uncommon to find ROI being calculated as an afterthought to increase a project's budget or extend its life when it is running out of money and/or behind schedule.

Any ROI analysis must include the following activities (as defined by PMBOK):

• Business needs or project requirements.
• Stakeholder influences.
• Effect of the project on related business processes.
• Risk factors.
• Justification - benefits versus cost.
• Summary budget.

In its most elementary form, ROI is the ratio of expected benefits to expected cost. Therefore,
ROI = (value of expected benefits / expected cost) * 100

Knowing your ROI has some very definite advantages:

• It allows projects in a company to be compared using a common set of metrics for establishing funding priorities which in turn determines when and if a project will be green-lighted.
• It provides an opportunity to understand the impact of a project's investment cost on the company as a whole since a ROI calculation analyzes the project's effect on business processes throughout the company.
• It quantifies the business expectations from a project which in turn can be used to determine whether the project was successful.

Orthogonal Array Testing Strategy (OATS)

One of the primary goals of software testing is to find the maximum number of defects (bugs) using a minimum set of test cases. There is a testing method that helps achieve this goal called the Orthogonal Array Testing Strategy (OATS). This is a statistical method aimed at maximizing error detection while reducing the number of test cases by using pair-wise testing.

What is pair-wise testing?
Let us assume that the software being tested has 5 variables each of which can assume 4 states. The number of test cases that will be required to test all possible combinations is 4 X 4 X 4 X 4 X 4 = 1024. Researchers at Bell Communication Laboratories in the late 1990s found that most defects were caused by incorrect values of a single variable or by values of certain pairs of interacting variables.

Defects caused by specific states or values of a single variable are called single-mode faults. This implies that we could detect all single-mode faults through 4 + 4 + 4 + 4 + 4 = 20 test cases.

Defects that occur when a combination of two variables assume specific states (values) are called double-mode faults. This is an indication of harmful interaction between two variables when they assume certain values. For purposes of illustration, let us assume that we are able to identify 6 variable-pairs with harmful interactions from among the 5 variables. Each variable-pair will require 4 X 4 = 16 test cases to exhaustively test all possible combinations. For 6 variable pairs, a total of 16 X 6 = 96 test cases will be required.

Thus, using the OATS methodology the total number of test cases required to detect all single and double-mode defects is only 20 + 96 = 116 as compared to 1024 test cases required using traditional test methods.

OATS, in effect, provides a statistical method to test pair-wise interactions through the use of orthogonal arrays. An orthogonal array is a rectangular matrix where rows represent test cases (runs) and columns represent variables (factors) being tested. The different states or values that each variable can assume are called levels. The underlying rationale of this technique is based on the hypothesis that almost all defects in software are due to either specific levels of a single factor or due to pair-wise interactions of factors at certain levels. One of the major challenges of this approach is to identify all pair-wise combinations that give rise to harmful interactions.

However the major advantages of OATS are as follows:

• Lower number of test cases.
• All single-mode and double-mode defects are uncovered which account for more than 95% of the bugs.
• Improved productivity due to reduced test cycles and testing times.

Software Quality

 

The Long Island Chapter (Section 303)
of the
American Society of Quality (ASQ)
presents an evening discussion
on
Software Quality

Every day, companies around the world struggle with issues related to software quality. How would you rate the quality of software developed in your company? How many discussions have you had with your engineering teams or senior management about the quality of your software? Does your company have measurable software quality standards? Are your customers satisfied with the quality of your software? Software errors cost the U.S. economy more than $60 billion annually in actual damages. Software bugs are not just annoying, they can be destructive and deadly.

Learn to recognize and remove defects during the initial phases of software development. It costs 100 times more to remove a defect in the operations phase than during the development phase of the software development life cycle (SDLC).

Presented by
Samuel Prasad, PhD, PMP, CSQE
ASQ LI Web Site Chair

Thursday, June 24th, 6:30 – 8:30 PM
Bertucci’s Restaurant
Melville, NY

Click here to view the presentation.