Executive MBA Programs

Posts Tagged ‘Management’

An MBA is a professional degree that opens various doors of opportunities into highly-sought-after positions in consulting, investment banking, venture capital and other areas. In the time span of two years or less, an MBA course makes you  well-versed in areas such as finance, management, marketing, human resource management, Operations, strategy etc.

But there are many specialization and several classes of Institutions, inside the country or abroad – option are many and confusions are many fold. So let’s move with us to remove the layers of confusion.

Who can go for an MBA?
Students – Any graduate can go for this more market-worthy qualification.
Working Executives – An already employed person who wants to move up in his/her career, those who simply want to increase their pay packets, enhance knowledge in managerial domains, make a mid career change or to attain greater job mobility.
Entrepreneurs & business heirs – An entrepreneur or business heir moves towards an MBA to acquire the knowledge that could help him to create, sustain and spread his business empire.

Available Program Options:

Full  Time MBA Part Time MBA Executive MBA

Each of these program options possesses their own benefits and drawbacks and selection of a particular program depends on the individual. The executive
program is best suited for those applicants who have more senior level work experience.

Admission Process- Various Management Exams in India:
To get admission at a reputed B-School, you need to perform well in the management entrance tests like Common Admission Test (CAT) conducted by the

Indian Institutes of Management, XAT conducted by XLRI Jamshedpur, IIFT admission test, admission test for FMS Delhi, MAT conducted by AIMA, SNAP Test by

Symbiosis, Pune NMAT by AIMA for NMIMS Mumbai and relevant state level common entrance test for business schools in various states.
How to select a B- school:
There are several classes of Institutions, inside the country or abroad – options are many and the task of selecting a right management institute becomes quite

difficult for a student. Although a lot of surveys and rankings are published throughout the year but theses surveys and rankings more or less creates

confusion in the minds of students. A student should judge an institute on his own predefined criteria. According to us, following are the most important

factors that should be considered while selecting a management institute:

Image of the Institute Placements Faculty members Infrastructure Quality of students Corporate and Industrial linkage and association Location

Read More www.admissionsupport.com

Rejuvenate the old Software Development using Agile Management & Six sigma

                                                                                                   *V V Narendra Kumar

                                                                                                                K.Kiran Kumar

                                                                                                                                K.Ravi

                                                        Abstract

For some time, management thinkers (and thinking managers) have been stressing the urgent need for radical new approaches to the corporation. In this paradigm, the bottom line cedes its pre-eminence to the top: the corporation concentrates on developing new revenue streams from new products and services, while optimising income from existing lines through innovative marketing and rapid exploitation of changing customer needs and tastes. The new kind of corporation is, above all, ‘agile’.

 The dictionary defines ‘agile’ as ‘nimble or active: quick-moving and supple’. For decades, the big business has been compared to a supertanker, which can only be turned at lugubrious speed. Top managers fret about the lack of creativity and innovation beneath them, below the supertanker’s decks, but their own decision-making processes and command structures stultify efforts – even ones which they themselves have promoted – to develop the new and rejuvenate the old.

 The Concept of Agile Management

The new changeability is demanded in every major area of corporate strategy and tactics. Like it or not, every corporation belongs in a web (or webs), an eco-system of alliances, partnerships, sub-systems, processes, lines of business, collaborators, etc., none of which is guaranteed any permanence. Hierarchy, dominant market share, vertical integration and economies of scale were the traditional means of mastering the complexities of large organizations – for ever. Today, all four pillars have been undermined.

 Hierarchy has very little place in an organization which depends on free-thinking, self-managing innovators at all levels. Formerly impregnable market shares have been undermined by aggressive newcomers in many markets. Vertical integration makes no sense when specialist, horizontal component suppliers can achieve economies of technology and scale far greater than those of vertical generalists.

 Telescope to kaleidoscope

The management metaphor has moved from telescope to kaleidoscope. Where once top managers could focus on their own concerns, with little need for peripheral vision, they now view a constantly changing pattern of shapes, sizes and colours, from which they must try to make sense. It sounds like an awesome task. It would have been impossible save for the advances in IT, which animates and accelerates the agile corporation, setting it free to move from control to coordination of collaborative effort, from the status quo to the future.

 All truly agile corporations share this positive attitude to change and the future. What makes such agility possible? The first and paradoxical answer is that agility rests on stability: just as Olympic divers need a solid diving platform to launch their acrobatics, so a corporation must be solidly based in order to perform strategic twists and turns at speed. A key foundation is a large and well-nurtured base of customers who respect the supplier. That respect can only be earned by consistent attributes: top quality, excellent service, and great innovation.

 The second answer is decentralization; diffuse authority to where it is most needed and can be most effectively applied. Let people take the initiatives that are best for their customers – in the famous microprocessor case, a Japanese calculator firm which wanted a set of Intel chips for its latest machine. An engineer named Ted Hoff earned immortality by wondering why all the circuits couldn’t be placed on a single piece of silicon. They could: other engineers took over and their prototype gave birth to great fortunes. The discipline was that of the technology, not of top management.

 Central management

Central management’s role in the agile corporation is partly to lay down exacting standards and to see that they are met. Management is also responsible for ensuring that decentralization is genuine. It uses its powers where they are helpful to ensure that its powers are not used where they hinder. This is another paradox, but the agile corporation thrives on paradox. It knows that there is no one right answer, only the best answer at the time, which will be replaced as soon as a better one arrives: and there’s always a better answer.

 That is a basic principle of kaizen, the continuous improvement mentioned above, and the essence of Total Quality Management. For a long time, to many conventional managers, TQM seemed foreign in both senses – an unwelcome and uncomfortable import from Japanese control freaks. In fact, TQM sprang from the work of an American, the remarkable W. Edwards Deming, who believed passionately in setting workpeople free from authoritarian controls so that they could do their jobs better – much better. Whether or not companies use TQM or its close relative, Six Sigma, the agile principle is the same: give individuals control over their own work and its improvement, individually and in the group. So, are you agile? Can you:

• deliberately fuse old and new?

• blend group working with real individual fulfilment?

• combine short-term, medium-term and long-term, without sacrificing any of the three?
• achieve both discipline and freedom?

• pursue commercialism with humanity?

• combine globalism with local, national and regional marketing?

• give the customers what they want while leading them to want it?

• strengthen the old while nourishing the new?

• throw caution to the wind, yet also avoid undue risk?

• grow fast while not overstretching the company by exceeding ‘the limits to growth’?

Sometimes these limits are immediately obvious, like shortages of production capacity, or component supply, or unsaturated markets to exploit. More often, the limits are less specific, compounded of several elements, including competitive actions and reactions, market trends, organisational responsiveness, environmental factors, etc. Taking the long view, the limits seem almost arithmetical: a corporation aiming to grow its earnings per share by 15% compound will have to double in five years, quadruple in ten and octuple in fifteen. The bigger the base, the more highly improbable the growth.

Decentralised Fleet

One remedy was well expressed by one CEO, who wanted to replace his supertanker by a fleet of decentralized motor-boats, speedy and powerful autonomous units that (unlike the unwieldy supertanker) could turn on a dime as they pursued their opportunities and repelled their threats. Few chief executives, however, have found it easy or quick to dictate and achieve this dynamic change in their fleets from stability to agility. Top-down initiatives have run into resistance from senior and middle management – resistance which is insidious and difficult to conquer.

The agile answer is to remove the top-down element from the initiatives – a reform which is at last easier done than said, thanks to informal, internal changes that have increased the agility quotient in all businesses. None of these changes is more important than the spread of multi-disciplinary, cross-functional teams which are formed to tackle projects and which last only as long as the project. Nobody ordained this fundamental reform, but today managers can easily spend half their time in ad hoc teams, the building blocks of the agile corporation.

Team remits may well extend beyond the boundaries of the corporation, into the territory of customers, suppliers or even competitors. The team thus bypasses formal structures and can create its own modus operandi. Time and again, project management by teams has proven its ability to make impossible deadlines possible. ‘Skunk works’, project teams and other ‘hot groups’ have created new heroes as well as new products and services.

Leadership of teams can pass from hand to hand, depending on whose authority of expertise is most relevant. The kaleidoscopic corporation thus breaks away from the old ideas of rank, status and chains of command and communication. The agile corporation relies on people doing what comes naturally, intuitively and voluntarily. Many observers have puzzled about the fact that employees in the mass in general resist change more than they do as individuals – even when the proposal is manifestly beneficial to their individual interests.

Guarding the status quo

This obstructive mass mentality reinforces the corporation’s role as guardian of the status quo. That automatically makes it the enemy of the new. There are obstinate, talented people like Ted Hoff inside every organization: the supreme test of agility is whether the organization frustrates that individual talent or thrives on its expression. The new agile approach optimizes the return on human capital employed by facilitating and grouping the use of human talents wherever, whenever or however they are needed.

This inevitably hinges on using new technologies to the full – above all those of information and communication. Organizations have always been machines for controlling and distributing information. Corporate arthritis followed when the messaging machinery became more important than the message. The aim was laudable: to attain disciplined, orderly, regular efficiency. The result was lamentable: wholes worth much less than their parts. Agile firms treat their parts as more important than the whole – and end up with a total entity that much outweighs those parts.

 Anyone who has ever been responsible for managing software development projects knows that software is not easy. Successfully coordinating and dealing with project sponsors, customers, team members, technology issues, and changing requirements challenges even the most experienced project leader.

 Leading projects in an environment that embraces both rapid delivery and change can prove even more daunting. Yet individuals with the desire to change the fundamental rules of the software game and accept the empirical nature of software development are faced with numerous opportunities. In order to capitalize on the evolutionary nature of agile development, today’s leadership community must also focus on 7 key aspects associated with of agile development: Courage, Context, Course, Cadence, Cost, Commitment, and Creativity.

 7  C’s of Agile Management

 Courage

            Also one of the four primary values identified in Kent Beck’s Extreme Programming Explained, courage takes on a much broader and more strategic meaning outside the boundaries of programming. Software development requires many interfaces – customers, other project teams, customer support, professional services, external stakeholders, human resources, and many more – and the confidence to step up to the plate and be willing to enact positive change in the face of tradition can be a risky, but ultimately very rewarding experience.

 

            Agile development is definitely not for the faint of heart. This does not mean that project management won’t ultimately be simplified, but rather that any new way of doing business requires practice and hard work. Agile leaders cannot be afraid to fail, especially during early iterations. With agile development, at least failures are typically limited in scope to a few weeks, at which point you can reevaluate the situation and adapt accordingly. These early iterations should be used to learn, adjust, and stabilize.

Teams, and people, generally get good at what they practice. In agile development, planning, estimating, testing, and delivery, occur every few weeks as opposed to once every year. As a result, teams quickly develop a rhythm. By focusing on removing obstacles that get in the way and allowing this rhythm to emerge, agile leaders set the stage for improvement, predictability, and success. While still in the heat of software delivery battle, a vast majority of agile teams look back after six months, see the improvement, and wonder how they ever could have successfully delivered software any other way.

 Context

            With much of the fundamental project infrastructure (scope, priorities, estimates, schedules, risks, etc.) in a state of flux, it has never been more important to steer and manage actions and decisions within an overall business context. While functional value can oftentimes drive the details of a project, business values need to help drive project goals. Force hard decisions about the business and project context as early as possible.

 Get as simple as possible answers to key questions such as:

• What is the vision for the project?

• What are the primary goals and business drivers of the project?

• What are the values that should drive key project and product decisions?

• What are the expectations of project sponsors and stakeholders?

 The answers to these questions serve as the basis for future decision-making, as well as a thread that can prevent a project from spiraling out of control. Additionally, the degree of visibility afforded these priorities can serve as a foundation for managing conflict and stakeholder negotiations. Many teams document answers to the above on a single page or project web page, and keep them visible throughout the life of the project. These answers often serve as a bar to which you will be held accountable.

 Course

            Context and course are complementary ideals. Whereas context defines overall circumstances, course defines direction and progress. Just because some agile approaches reference not looking in detail beyond one to two iterations, do not be lured into believing that longer range planning is not necessary or valuable. Longer-term software plans serve as a roadmap for important interim business and project decisions. Iteration, milestone, and release plans remain critical components in planning and measuring progress. Keep in mind that as you plan further out, confidence levels diminish, but a minimum three- to-six-month roadmap serves as a continuous reality check in the face of a changing environment.

             Make a concerted effort at least every iteration to revisit objectives, reconcile overall direction, review time-frames and deadlines, and communicate variances. Reality has proven that rarely does time get made up on software projects. This is especially true in the world of agile development. In agile development, change is accepted and even fostered for business reasons, so in addition to delivering early and often, be prepared to communicate early and often. Unlike traditional projects environments where the feedback loop can span quarters or even years, many more successful agile project teams

communicate directly with key business and management stakeholders as often as each iteration.

 nce

            One can consistently use the concept of cadence, or rhythm, to communicate one of the most beneficial effects of agile development. Most successful agile teams get into a powerful groove that can significantly benefit team confidence as well as overall project reliability.

 

            Similarly, teams’ deep grasp of iterative and incremental delivery in its complete sense can serve as significant risk mitigator. Instead of delivering once a year or more, agile teams deliver working, tested, installable software every iteration. In this type of environment, unexpected loose ends greatly diminish, defects are much easier to manage, integrated builds are second nature, and production deployment becomes much more streamlined and foolproof. This is not to say that some problems will not arise, but those that do will be much more manageable.

             To early practitioners, this team rhythm is a goal to strive for as early as possible. To experienced practitioners, this rhythm greatly simplifies the task of leading agile development efforts. Many agile teams  have worked with achieve a much higher degree of predictability than with traditional methods. Simply having a quantifiable, accurate history of estimation and delivery can tremendously simplify planning and improves reliability.

 Cost

            Even agile development cannot escape the associated financial implications of software development. The challenge, and advantage, of agile development is the opportunity to justify the cost with business value and customer benefit throughout the process, as opposed to once at the very end. In addition, instead of managing projects as cost centers, agile development also provides the opportunity to view software development as an investment, with a goal being to achieve the highest possible returns earliest in the development cycle.

             While you may not have the same direct influence over business benefit that you do over cost, the opportunity to allow the business to extract value sooner rather than later, continuously align business and technology goals, and adjust to changing business dynamics is of tremendous value. It is because of this aptitude for change that financial considerations must continue to remain front and center. While the cost model for most agile development projects is fairly straightforward, “cost per iteration” is not something that many organizations have either experienced or understand. Fortunately, many consulting companies and software organizations have made the transition to a simplified project costing model, multiplying the approximate cost per person for the entire team by the length of an iteration to derive ongoing financial impact (i.e., $80,000 per iteration). While not as sophisticated as traditional staffing and resource allocation models, this type of analysis and justification can be just as accurate.

 Commitment-Based

            During the development of a system, software modules can be viewed in terms of their commitments: the constraints imposed by their own structure and behavior and by their relationships with other modules (in terms of resource consumption, data requirements. etc.). The Comet system uses explicit representation and reasoning with commitments to aid the software design and development process-in particular, to lead software developers to make decisions that result in reuse. Developers can examine the commitments that must be met in order to include an existing module, and can explore how commitments change when modules are modified.

 Creativity

Creating Software is one of the most creative activities that humans undertake. The main limitation in software is the Human Imagination, and the limits on that are all self imposed. Through the Software Engineering model we see a linear, sequential model of Software Development, something that drastically reduces our ability to create really great software.

Through the application of creativity, it is possible to create truly great software. The only problem is that doing so requires that developers have the freedom to explore different designs, and the ability to choose the design that most closely matches the spirit of the requirements rather than the letter of the requirements documents.

 Software Creativity occurs when we take time to explore the design space of possibilities, rather than immediately fixating on the first solution that comes to mind. A good example of this is my current favorite development tool, Borland Delphi with it’s tightly integrated code and graphical editors, allowing a developer to make changes either via the text editor or any of the other tools. Now if they can only come out with a Java or C++ version. (1997 addition)  C++Builder and JBuilder are both answers to this request.

An implication is that developers need to be concerned about creativity. Although most people would ascribe to the idea that software development is a creative activity, few people think that they are really creative. The effect of this on software development is drastic. Few developers learn how to really evaluate designs, since one consequence of being able to evaluate a design is the need to create alternatives if the first one is lacking.

 Wisdom in Agile Management

 The Whitewater Interactive System Development with Object Models (Wisdom) addresses the needs of small development teams who are required to build and maintain the highest quality interactive systems (Nunes & Cunha, 2000). The Wisdom methodology has three key components:

 1. A software process based on user-centered, evolutionary, and rapid prototyping model

2. A set of conceptual modeling notations that support the modeling of functional and nonfunctional components.

 3. A project management philosophy based on tool usage standards and open Documentation

Advantages of Agile Development

 What are the advantages of Agile Management & development methods???

The benefits are significant and include:

• Shortened development cycle-time of 75%

• Higher stability of work-loads

• Higher utilization of work-load, that is, developing large-scale, software systems with a fixed number of developers,

• Higher flexibility to change of Management & development plans,

• Higher quality by earlier feedback from the customers.

 Limitations of Agile Development

 What are the limitations of agile development methods???

The limitations of Agile Management methods are:

• Agile development methods do not scale. Due to the integrative approach, it is hard for some to understand exactly where the project stands. In a typical environment, upper management wants to know when each phase is completed such as design, code, or test. Thus, due to the various iteration steps, it can be hard to understand if the project is on track

• Agile management methods do not handle large teams well. The approach only works for small to medium-sized teams

• Agile development requires highly skilled and highly motivated individuals, which may not always be existent. Agile places a premium on having premium people

 Users of Agile Management Methods

Are there any companies which are using Agile Management methods???

These companies are making use of Agile development methods:

• Northrop Grumman Commercial Aircraft division

• Texas Instrument

• Marlow

• Loral Vought Systems

• Center for Collaborative Manufacturing

• E-systems

• Tracor, Inc (UTA, date not mentioned).

Escrow.com also uses agile development methods. Escrow.com has documented the results of their success with agile development methods in this table:

 Reconcile Six Sigma with Agile software development

There is often a cultural conflict between adaptive/Agile software groups and process improvement groups in organizations that are trying to implement a method such as Six Sigma. Objectively, however, there is no fundamental conflict between the two. Agile development focuses strictly on satisfying customer-defined requirements with a minimum of administrative overhead. Six Sigma focuses on satisfying customer-defined requirements by applying rigorous process controls. The difference lies in the implementation; the end goal is the same. Therefore, there may be little or nothing to “reconcile.” It may only be a question of understanding when to apply each approach, and at what level to incorporate each into the standard practices of the organization.

Compare the way an Agile software development project typically runs with the way Six Sigma approaches the problem of improving an existing business process. The Six Sigma DMAIC process closely parallels the Agile project approach. The Define in DMAIC means to quantify the desired results based on the voice of the customer, a critical concept in both approaches. The Measure in DMAIC means to keep track of which causes are contributing to which effects. The Improve in DMAIC means just what it says. The Control in DMAIC is analogous to the Agile concept of continuous learning, well known in organizational science as double-loop organizational learning. There is nothing unfamiliar or contradictory here, at least at a conceptual level.

Six Sigma and Agile development are both dedicated to reducing failure rates and improving customer satisfaction. They represent very different mindsets about how that is to be accomplished, though. In answer to the failure of heavyweight process controls to assure IT project success, Six Sigma imposes even heavier process controls in order to gain a thorough understanding of cause and effect. The Agile approach is based on an entirely different philosophy; reducing formal controls in order to give qualified professionals the freedom to apply critical thinking skills and creativity to unique problems. The two approaches are effective in different situations.

In a limited domain such as a manufacturing process, it makes perfect sense to gain a thorough understanding of cause and effect. In a service operation it may make sense, too, depending on whether it is important to minimize variation in some factor (remember that the main purpose of Six Sigma is to minimize variation). An example often used in Six Sigma training is a pizza delivery service that wants to keep delivery times within the bounds promised to customers and ensure the pizzas are all consistent — height of shell, evenness of diameter, color of shell. It is possible to analyze all the factors that contribute to these quality factors and identify areas for improvement.

You can see that the restaurant example cited earlier in this article represents a very different problem in a very different business context, although both examples have something to do with food service. It is important to understand the characteristics of the business operation to be measured in order to choose an appropriate method. It is easy to assume that any approach that worked in one food service situation must work in another; or that any method that worked in one information technology situation must work in another. That isn’t necessarily true.

Software implementation and software development are not the same type of problem. Six Sigma is an effective method for software implementation projects in particular.

      Statistical process control methods have a long history, going back to the work of W. Edwards Deming some 50 years ago. Of the many SPC methodologies, the best known and most widely applied have been Total Quality Management, Kaizen, and Six Sigma. When applied intelligently to the types of problems they are meant to address, SPC methods can yield significant benefit.

A website dedicated to the application of Six Sigma to information technology includes an article by Gary Gack, a founding partner of Six Sigma Advantage, summarizing the Six Sigma approach to software implementation projects. The article shows there are many fundamental similarities in the philosophies of Agile and Six Sigma, as applied to software implementation.

An interesting point, and one we should not overlook, is that the author distinguishes between software development and software implementation projects. The author claims Six Sigma is an effective method for software implementation projects in particular; not for software development projects. This, from a man with 40 years IT experience, a Six Sigma Black Belt, an ASQ-certified software quality engineer, and an MBA from the Wharton School.

 Should we manage the software development process as such with Six Sigma?

One can define three different relationships that companies have with information technology: A primary technology company creates new hardware and/or software, a tertiary technology company uses those products to support its own business operations, and a secondary technology company helps tertiary companies figure out the products offered by primary companies. The process of software development is a business operation in its own right only for primary technology companies; for all others, it is simply a support function. Any method that treats software development at the same level as a true business operation is going to miss the target to some degree.

Based on the preceding discussion, any process that is both a business process and a manufacturing process may benefit from the Six Sigma method of quality control. This is shown by the following truth table:

BP

MP

BP AND MP

F

F

F

F

T

F

T

F

F

T

T

T

We have shown that software development is not a manufacturing process in any case. We have also shown that software development is a business process only when the core business of a company is software development. For secondary and tertiary technology companies, software development is only a supporting activity, and not a business process in its own right. Finally, we have shown that the underlying philosophies of Agile development and Six Sigma management are different. The former seeks to minimize administrative overhead to leave professionals free to do the right thing, while the latter depends on formal documents, hand-offs, and abstract data analysis to enforce quality on a process from without. Therefore, the question of whether Six Sigma applies directly to an Agile software development process in a tertiary technology company is answered by the first row in the truth table.

But we still don’t have a final answer. The consultancy that is helping us implement Six Sigma has a simple decision flowchart to help with the selection of Six Sigma projects. It looks something like this:

Figure 1: Choosing a Six Sigma project

he flowchart appears straightforward, but in reality it is subject to a great deal of interpretation. For example, the assessment of a project idea is different if the idea pertains to business process improvement than if the idea pertains to a software development project. Unless the company is a primary technology company, the software development process is not a business process in its own right; it is only a supporting function. (The features of a software package are important to the business process, but the way the software was built is irrelevant.) Thus, the level of detail of the two types of project ideas is quite different.

 Let’s modify the flowchart a bit to make it clear that we are considering ideas for business process improvement as candidates for Six Sigma, rather than just any and all project ideas:

Figure 2: Does Six Sigma fit a business process improvement idea?

In addition, the understanding of terms varies depending on the background and area of focus of the person reading the flowchart. A business person assessing a business process will have a different understanding of “Solution Known” than a software development professional assessing a software project idea. To the former, “Solution Known” means that the entire end game is fully understood, and therefore there is no need to apply Six Sigma or a similar method to learn how to improve the business process. To the latter, “Solution Known” may only mean that the approach to discovering a solution is known. That is simply part and parcel of professional software work, and does not represent an “unknown” that requires statistical analysis. This is especially true when Agile methods are used.

In an organization that uses both predictive and adaptive methods for software development depending on the characteristics of a given project, the assessment is still more variable. In that case, “Solution Known” may mean even less than in the simpler cases. It may mean nothing more than we “know” we have to apply another decision-making approach to the problem. For example, if we are working in a tertiary technology company and we are assessing a software development proposal, as opposed to a business process improvement proposal, then “Solution Known” means we can assess uncertainty and urgency to choose either a predictive or an adaptive approach to software development. To a software professional, this is a case of “Just Do It.” There are further decisions to make regarding the choice of approach, choice of methodology, and so forth, but to a software professional this is all “known” activity.

To a business professional, it does not seem quite so secure. Instead, it sounds as if a great deal is still not known. If we are assessing a proposal for business process improvement rather than for software development, then the business professional would be correct. The approach to discovering the right solution to a business process improvement problem is to apply Six Sigma or a similar method. It is an entirely different type of question than in the software development case. It is very important, then, to understand clearly and objectively whether you are assessing a business process improvement project idea or a software development project idea.

Obviously, since nearly all business processes are supported by application software, software development projects will fall out of any business process improvement initiative. That is only to be expected. However, each of those development projects is not a business process in its own right, and need not be managed in the same way as the overarching business process is managed. That would be a misapplication of Six Sigma.

Another decision point is whether the problem is the result of a repetitive process. We have already explained that software development is not a repetitive process in the same sense as a manufacturing process. It is more analogous to the construction industry, in which certain well-known engineering principles are applied to every project, and certain well-known design patterns may be applied, but each project is unique — with the exception of manufactured housing components, there is no assembly line process on a construction project. In software development there is absolutely no assembly line process, since any given piece of software is only developed once. When a software development project is being assessed by this flowchart, the answer to this question must always be “No.”  

However, a business process improvement initiative may be inspired by a problem in a repetitive process, and the solution may, in turn, spawn a software development process. It is important in this case to understand the differences between business processes and software development processes. In particular, we must keep in mind that the two are really at different levels of detail.

 Is it ever appropriate to apply Six Sigma to a software development process? Yes. In a primary technology company whose core business model includes software development along with marketing and/or consulting services, the software development process is a business process. The role of software development activities in a primary technology company is very different from that in a secondary or tertiary technology company.

 For example, consider the software firm S1, specializing in enterprise software for the banking industry. S1 uses a predictive (waterfall) software development methodology based on the Rational Unified Process (RUP). Their customized RUP process is transparent to customers (they can view the bug tracking system directly), is based on frequent, direct communication among all team members, and enjoys the advantages of iterative development. But it is a predictive process overall, since the product line must meet known regulatory requirements, support industry best practices, and interface with other mainstream banking software products. Since software development is the company’s core business practice, and since a predictive development approach lends itself to formal process controls, and since S1 develops its product line on a fixed release schedule (thus making their development practice a repetitive process), S1 is an organization that could apply Six Sigma directly to its software development process. I don’t know whether they do so; I only cite this as a counterexample to the software development process used at a tertiary technology company, to show that some software development processes may benefit from Six Sigma while others may not.

 Here is a version of the decision flowchart that takes into account the fact software development is a business process for some organizations, and only a support function for others.

Figure 3: What approach should we apply to a software development idea?

 It depends.

      If software development is a core business practice and the development follows an approach based on documentation and checkpoints, then yes. If software development is a support function and/or the development approach is based on direct communication and informal methods, then no.

 Ask the right questions or get the wrong answer

      The value of the answer one receives from an oracle, whether ancient or modern, depends on the formulation of the question. “Their answers were carefully doubled – and might have one of two or more meanings. This was certainly wise, and indicated that the oracle was not a fool, whatever might have been thought or said of its questioners.” It is very easy for the questioner to fool himself by asking the wrong question, or by asking the right question in the wrong way, or by being too eager to interpret the answer in the way he desires. We must be careful of this pitfall when asking whether Six Sigma applies to any given process in our enterprise.

 One can argue that business application software is a critical part of any contemporary business process even in a tertiary technology company. That is certainly true, but does it imply anything about the applicability of Six Sigma to the company’s internal software development process?

 Many business processes rely on telephone technology as well as on business application software. A back office operation that processes human resources requests or handles paperwork for loan servicing uses telephone technology extensively. What do we need to know about the telephone system to help those operations improve quality? The telephone system must support the features the workers need to do their jobs efficiently. Do we need to know about the telephone manufacturer’s assembly line process? Not at all.

 The same reasoning applies to the business application software that supports those business processes. We need to know that the software supports the features the workers need to do their jobs efficiently. We do not need to know anything about the software vendor’s development process. That is outside the scope of the business process we want to measure and control.

 To try and measure the software development process at a tertiary technology company is tantamount to measuring the manufacturing process at the company that makes your telephone, and then believing the information will give you insight into the quality of your own business processes, which have nothing to do with making telephones. It would merely be weighing the leftover green peas.

 The bottom line is that Six Sigma and Agile development methods are two different tools that apply to two different types of problems. Neither is a panacea, and neither should trump the other as an organization’s sole approach to problems.

 Conclusions

            There are so many things that today’s project leaders can pay attention to during software development projects. The key is to focus on the fewest things that matter, simplifying and streamlining those aspects of software development [outside of working software which should be a given that deliver the greatest value to the business and the team. Especially in an arena of high-change, rapid delivery, and continuous feedback, the need for leadership has never been greater. While the physical time required for actually planning and tracking a project may lessen, the time commitment associated with coordinating, Communicating, and guiding in a rapidly evolving environment can be amplified exponentially. By maintaining a laser-focus on the incremental delivery of business value and at the same time giving appropriate attention to the  areas referenced in this article, hopefully the process of leading in an agile world can actually be simplified.

 References:                                     

.

References:                                    

1.      5 C's of Agile Management ,by Robert Holler, President & CEO, VersionOne
2.    Six Sigma as the Agile Future? David J. Anderson,blog
3.      Agile Management for Software Engineering-applying the theory of Constraints for Business Results-by David J Anderson, COAD Series.

4.      Integrating Project Management Into a Six Sigma System,By Tony Jacowski- 5. Software Engineering, Pressman, 6th Edition, TMH

 

 

                             

 

Published several Articles on Datamining and Busines Intelligence.Interested areas are Software Engg,Datamining,DBMS,COBOL>presently faculty Alluri Institute of Manangement Sciences,Warangal,A.P.