After getting quality certification, one of the most important ways of pushing implementation is often verifying the success with periodical audit. “NC – Non Compliance” is a buzzword in software industry. You see various forms of audit - Internal, External, Statutory etc. These are conducted periodically. The frequency of such audits could be monthly, quarterly or annually. The non-compliance instances are discussed and actions are initiated. A lot of preparation is required before the scheduled audit. The audit report is prepared and it is sent to seniors. Normally, the success is judged based on % compliance. Bosses often ask for these reports for achieving higher compliance. Although an audit is important, one question keeps coming to my mind, “Does this add enough value for sustained improvement?” One may not have a very clear answer here as very often we come across high % compliance and on the other hand we also come across project failures. I’ll name this phenomenon as “Compliance -Correction “Syndrome.
Postmortem has its own importance and so is the audit. One can learn a lot from postmortem. Do you have a better way which can be used for sustained improvement and still one uses audit for some spot checks? Let us look at an analogy of One Way Street. Few of us must have been caught by the police while entering one way street from wrong side. Police imposes fine on violators. Normally, you find police standing on the other side of the road or at the exit point. The intention is to catch violator. Can we think differently? What about if police is deployed at the entry point? And he starts stopping vehicles entering one way street from the wrong side. This will certainly have an implication over the fine collection. I argue; it will have a better impact in bringing discipline and in bringing sustained improvement in behavior. Therefore, if the goal is not penalizing for doing a mistake you can always think of a better way of doing the same thing effectively.
I think we often miss the spirit of a quality standard. We start following in words and not in spirit. It is important to remain focused on the goal and look at the spirit of these quality standards. The moment you do that “Compliance” will have a lower ranking on your priority list. You will start thinking in terms of using quality for improvement.
I am sharing here an example from one of my project experience. We had a software project where we did not have conventional coding. The existing code was to be analyzed and appropriate documentation was to be created. Naturally, this project had a different lifecycle phases. At a higher level one can look at conventional Development Life cycle phases and customize the same to suit the specific needs of the project. The same was done here. All the quality steps like unit testing, review, testing was looked upon from project necessity perspective. All the stakeholders were taken in confidence and their concurrence were obtained on the customized processes applicable to the project. The team was empowered to tweak the process for better effectiveness as they proceeded on the project. Transparency, empowerment, and continuous learning were the buzz words in the project. The SQA played a role of reformer. He worked with project team to customize the process, remained an active participant throughout the life cycle. The result was phenomenal. Fortunately compliance in the audit process was 100%. Let us look at the results:
Test Cases Success Rate 95.74%
% Schedule Variance -15.38%
TDI’s to SP Ratio – Last Milestone 1.26 TDIs/SP
In the above table TDI’s to SP ratio is the measure of defect density and negative variance means savings. The defect density improved by 66% over the first iteration. Besides the positive metrics, the Client experience was superb.
I term this as an experience which is very positive. It is not oriented towards “Compliance-Correction” syndrome. Compliance here is a byproduct. One can repeat this every time irrespective of the type of project. I suggest the following steps:
1. Customize the Quality Steps looking at the type and need of the project. This step is critical. Look carefully at Design, Construction, Unit Testing, Review and Testing. Define the specific steps for each of them. Do not forget to make SQA as a partner here.
2. Work in a culture of transparency, empowerment and participation. This sounds a little theoretical. Believe me if you attempt it, you will find your own way for doing this. Success will teach you to follow this in all projects during your life time.
3. Listen to all stake holders. Be open for change.
4. The steps finalized as a part of customization, are not final. Tweak them as you progress based on your learning on the project.
5. Look at Customer Success Factor (CSF). It may be advisable to understand the personal success factors for the immediate customer contact and integrate those as a part of your project success. Define your measurements and success criteria in line with CSF to Monitor and control.
I have seen projects failing because the team simply does not do the basic simple steps as mentioned above. My advice is to remain focused, get out of “Compliance-Correction” syndrome and follow the above steps. You are bound to embrace success.
Thursday, July 15, 2010
Thursday, July 1, 2010
In the Wonderland of Quality Certification
I was a student of engineering. I have often heard student’s talk, “what principles are taught in class room and what get’s implemented in life are two different things”. This is because of the failure of implementation. I have a different opinion on the subject. I have always found that whatever principles are taught, they can be applied in totality in practice. The gap is often found in understanding and putting the principles in simple steps for implementation. The art of putting a principle in simple steps for implementation and the passion for implementation are the two keys for success. This is same as having an Engineering degree and being an engineer. I studied engineering and regularly scored high grades in Design, Applied Mechanics etc. But my work life began in Industrial Engineering field. I never practiced Design principles in my life. In practical sense I have an Engineering degree but I will not call myself an Engineer. To become an Engineer you need practice, an art of applying the principles in your practical life.
If I look at software engineering and quality movement, I often think the industry is generally suffering from similar “Degree Syndrome”. CMM, CMMI and ISO are the standards which have brought excellent principles in life. Many companies have graduated and have passed the examinations; the certification process. Rarely companies have applied these principles fully and reaped benefits. All these standards give you short of curriculum. The practitioner has to understand the principles, pass the exam and practice the art of implementing in real life. First two things always happen but the practice is always a victim. That’s the reason; many companies having CMM level 5 certifications are not able to produce consistent results.
Malcom Gladwell in his book “Outliers” has talked about a practice 10,000 hours to become expert in any field. I think this principle applies perfectly in quality implementation as well. In order to make the process seamless with the workflow, the company needs a practice of 10,000 hours or more. Practice has to be in such a way that it can be synthesized and can create a learning experience too. Project Managers often tell, “Let me complete the work then we will do the documentation”. If you hear such words in any company then you should conclude that the company lacks many more hours of practice before it reaches the level of maturity in applying the principles which the degree; certification has provided. The result will never come until one has attained a perfect integration of process in work flow. The work and process have to be seen as a single entity and not two separate tasks. As long as they are seen as two separate tasks, the effectiveness of process rigor will be farfetched.
I would like to give a simple analogy of process integration with work. Let us take a payment transaction in a privately owned company. The payment assistant normally makes payment on authorization of the payment. There is a process of request, authorization, verification, payment and finally acknowledgement. The person making the payment considers all these as a single process of payment. Even if the owner asks for 10,000 rupees, the payment assistant creates a voucher and gets his signature or signature of his secretary before making any payment. This is a perfect integration of documentation with the workflow. You find such process implementation work flawlessly.
I therefore suggest implementation is a bigger task then getting certification. One needs to get out of “Degree Syndrome”. Getting a degree is the first step. Implementation of the principles needs understanding of the principle, putting them in simple steps and finally nitrating with the overall work. This simple principle can act as a guide for process implementation and therefore leads to success. Just ensure that the basics are being done, they are integrated with work, documentation is not separate than the work; you are bound to succeed.
If I look at software engineering and quality movement, I often think the industry is generally suffering from similar “Degree Syndrome”. CMM, CMMI and ISO are the standards which have brought excellent principles in life. Many companies have graduated and have passed the examinations; the certification process. Rarely companies have applied these principles fully and reaped benefits. All these standards give you short of curriculum. The practitioner has to understand the principles, pass the exam and practice the art of implementing in real life. First two things always happen but the practice is always a victim. That’s the reason; many companies having CMM level 5 certifications are not able to produce consistent results.
Malcom Gladwell in his book “Outliers” has talked about a practice 10,000 hours to become expert in any field. I think this principle applies perfectly in quality implementation as well. In order to make the process seamless with the workflow, the company needs a practice of 10,000 hours or more. Practice has to be in such a way that it can be synthesized and can create a learning experience too. Project Managers often tell, “Let me complete the work then we will do the documentation”. If you hear such words in any company then you should conclude that the company lacks many more hours of practice before it reaches the level of maturity in applying the principles which the degree; certification has provided. The result will never come until one has attained a perfect integration of process in work flow. The work and process have to be seen as a single entity and not two separate tasks. As long as they are seen as two separate tasks, the effectiveness of process rigor will be farfetched.
I would like to give a simple analogy of process integration with work. Let us take a payment transaction in a privately owned company. The payment assistant normally makes payment on authorization of the payment. There is a process of request, authorization, verification, payment and finally acknowledgement. The person making the payment considers all these as a single process of payment. Even if the owner asks for 10,000 rupees, the payment assistant creates a voucher and gets his signature or signature of his secretary before making any payment. This is a perfect integration of documentation with the workflow. You find such process implementation work flawlessly.
I therefore suggest implementation is a bigger task then getting certification. One needs to get out of “Degree Syndrome”. Getting a degree is the first step. Implementation of the principles needs understanding of the principle, putting them in simple steps and finally nitrating with the overall work. This simple principle can act as a guide for process implementation and therefore leads to success. Just ensure that the basics are being done, they are integrated with work, documentation is not separate than the work; you are bound to succeed.
Thursday, June 24, 2010
Doing More with Less
Custom development in software industry has come a long way. Today more and more companies are looking for off-the-shelf solutions. It goes without saying that such solutions may not meet all the needs of a company. But it certainly is quick to implement, cost effective, and scalable. Even today we come across many cases, where custom solutions remain inevitable for a client. There may be couple of reasons including specific application niche, where no readymade solutions exists.
This emerging situation brings a new set of challenges for Development, Project Management etc. Let us take a case of winning a project. Earlier we devoted our time to accuracy of estimates. Various methods evolved like Function Point Analysis, Work Breakdown Structure etc. The software vendor matured their practices and came up with robust estimation and sizing model. The accurate sizing is necessary, but does not guarantee success. Such failure creates a tremendous disconnect in the organization’s functional entities like sales, solutions, operations etc.
The myth here is sizing what? Sizing is appropriate, only if solutions approach is similar and cost effective. I have seen companies losing business to competition, who are Agile, Innovative and utilize its software asset base to provide cost effective solution to the client. Therefore as a management, as a Project Manager, as an architect we have to think differently. Some of the experience I would like to share here:
1. The Brick and Mortar age is gone. Building everything from scratch will not work in an era of off-the-shelf products. Avoid Brick & Mortar based solutions as far as possible.
2. Reusability, Replication are some of the mantras for success. We have been talking this for ages. Putting this in practice requires some strategic thinking and direction. These directions will come from focus and scale. Companies touching everything are not able to compete with companies, who are specialists in a domain, have more opportunities in the same area. They leverage their asset base better and come up with a more cost effective solution despite having rate disadvantage. What I am referring here is even a local western country vendor can easily compete with an offshore vendor from a low cost location utilizing the above principles.
3. Building Tools and Templates: Tools and templates help in accelerating development. Their building efforts can be amortized over a large number of projects.
4. Technology developers have come up with language based frameworks, design patterns etc. Their efficient usage is paramount to stay competitive.
5. It is the time to look at innovative approach to solutioning. The old industrial engineering approach is very handy. Some of the principles from manufacturing like Kaizen and Lean manufacturing can be applied in software situations as well.
It is easier to talk about these principles than implementing them. This requires a strategic direction for the company to start with. Once you have strategic direction, you can start building assets and implement some of the thoughts mentioned above. This requires replicable work opportunities, economies of scale. The replicable opportunity has to be in domain and technology areas. One can not compete, if you are a generalist. Stay focused on a technology, specific domain, create scale, utilize five principles mentioned above, you will succeed.
Darwin’s principle for Evolution holds perfectly fine in this environment - “Struggle for existence and survival of the fittest”. This is a time of non-linear thinking. With smaller increase in resource base we need to deliver non-linear output. Do more with less- is the final goal. This is a paradigm shift. If you do it correctly, you could be more profitable and provide a very cost effective solution to your customer.
This emerging situation brings a new set of challenges for Development, Project Management etc. Let us take a case of winning a project. Earlier we devoted our time to accuracy of estimates. Various methods evolved like Function Point Analysis, Work Breakdown Structure etc. The software vendor matured their practices and came up with robust estimation and sizing model. The accurate sizing is necessary, but does not guarantee success. Such failure creates a tremendous disconnect in the organization’s functional entities like sales, solutions, operations etc.
The myth here is sizing what? Sizing is appropriate, only if solutions approach is similar and cost effective. I have seen companies losing business to competition, who are Agile, Innovative and utilize its software asset base to provide cost effective solution to the client. Therefore as a management, as a Project Manager, as an architect we have to think differently. Some of the experience I would like to share here:
1. The Brick and Mortar age is gone. Building everything from scratch will not work in an era of off-the-shelf products. Avoid Brick & Mortar based solutions as far as possible.
2. Reusability, Replication are some of the mantras for success. We have been talking this for ages. Putting this in practice requires some strategic thinking and direction. These directions will come from focus and scale. Companies touching everything are not able to compete with companies, who are specialists in a domain, have more opportunities in the same area. They leverage their asset base better and come up with a more cost effective solution despite having rate disadvantage. What I am referring here is even a local western country vendor can easily compete with an offshore vendor from a low cost location utilizing the above principles.
3. Building Tools and Templates: Tools and templates help in accelerating development. Their building efforts can be amortized over a large number of projects.
4. Technology developers have come up with language based frameworks, design patterns etc. Their efficient usage is paramount to stay competitive.
5. It is the time to look at innovative approach to solutioning. The old industrial engineering approach is very handy. Some of the principles from manufacturing like Kaizen and Lean manufacturing can be applied in software situations as well.
It is easier to talk about these principles than implementing them. This requires a strategic direction for the company to start with. Once you have strategic direction, you can start building assets and implement some of the thoughts mentioned above. This requires replicable work opportunities, economies of scale. The replicable opportunity has to be in domain and technology areas. One can not compete, if you are a generalist. Stay focused on a technology, specific domain, create scale, utilize five principles mentioned above, you will succeed.
Darwin’s principle for Evolution holds perfectly fine in this environment - “Struggle for existence and survival of the fittest”. This is a time of non-linear thinking. With smaller increase in resource base we need to deliver non-linear output. Do more with less- is the final goal. This is a paradigm shift. If you do it correctly, you could be more profitable and provide a very cost effective solution to your customer.
Thursday, June 17, 2010
Using Theory of Constraint to manage large Software Project
“The Goal” – a book written by Eliyahu M. Goldratt & Jeff Cox is reaching closer to 8 million copy sale. This is incredible. I am not sure how many business books have reached such a level. The sale clearly indicates something inherently great about this book. I found this book written in a story style. The concept of Theory Of Constraint ( TOC) is explained in a very simple language taking simple situations. I was thinking there could not have been better way to explain TOC concepts than the way explained by the authors. The examples are taken from manufacturing industry.
I am reproducing a short extract from the Preface of the book.
“Companies, even the relatively small ones, are incredibly complex. When facing complex systems, it is so easy to fall into the trap of looking for complicated solutions. Still, we all know that complicated solutions do not work! Instead, what we should do is realize that every complex system is based on inherent simplicity. The way to rapidly improve our systems is to search out that inherent simplicity and capitalize on it.”
I am sold on principle of simplicity. When I finished reading this book, I was struggling with a project of 50 persons with an estimated effort of 20 man years. The project was delayed. The completion date appeared like a moving goal post. It was challenging. Although TOC principles are primarily applicable to Manufacturing type of systems, I found it very relevant to apply the principle to solve the complex situation we were in.
We in software business talk about life cycles like Waterfall, Agile, Iterative etc. The principle of TOC can work in conjunction with any one of them. Let us look at the brief case study.
On 1st October 2009, we saw this project getting out of our hand. We brainstormed and brought major changes the way we managed the project. We looked at each element of project team. The team structure can be depicted as sequential block of related activities. Each block represented a processing station.
We noticed a lot of backlog, late working and low motivation at Integration station. UAT team, which was a Client team also, had a similar problem. The natural outcome was to define Goals for the project and structure the team around the defined goals. The goals were agreed as:
1. Improving throughput through the system.
2. Ensuring high quality of deliverables. It was thought to reduce UAT defects at least by 67%.
Besides the above goals, a working discipline was agreed to support the stated goals. Every station will work towards ensuring the utilization of critical stations ( Integration & Acceptance in this case) and the work allocation will be done to assist faster throughput and not ensuring higher utilization of the members in different stations. The work was structured in batches and batch movement across various stations was monitored and managed on above principles.
Implementing this discipline in the team faced resistance from both internal team members and the Client. A series of discussion were held with stakeholders and finally a concurrence from the customer was obtained for trying this out. We were confident to demonstrate the benefits within a week or so. This was used to make Client agree to watch the process for a fortnight.
After agreeing with the basic rules of the game, all team worked to support the goals. We carried through system of daily stand up call concentrating on three questions - what got done in last 24 hours, what are the plans for next 24 hours and what are the bottlenecks. We worked to solve the bottleneck.
The first batch with the new process was submitted on schedule. The result of the UAT was very encouraging and changed the morale of the team. People had renewed level of confidence. They were upbeat with the results. This changed the whole game. The theory was followed in word and spirit and in three months time the project got completed and accepted by the customer. Although we had a bad start, the excellent finish gave us excellent respectability from the client and great sense of achievement for all of us.
Software industry is gradually maturing. Time is getting apt for applying proven principles of manufacturing ( Factory Management Principles) in this maturing industry. TOC is one of them and I am upbeat with my experience on solving large complex project issues using this theory. It has worked well and can work with any life cycle selected for the project execution.
I am reproducing a short extract from the Preface of the book.
“Companies, even the relatively small ones, are incredibly complex. When facing complex systems, it is so easy to fall into the trap of looking for complicated solutions. Still, we all know that complicated solutions do not work! Instead, what we should do is realize that every complex system is based on inherent simplicity. The way to rapidly improve our systems is to search out that inherent simplicity and capitalize on it.”
I am sold on principle of simplicity. When I finished reading this book, I was struggling with a project of 50 persons with an estimated effort of 20 man years. The project was delayed. The completion date appeared like a moving goal post. It was challenging. Although TOC principles are primarily applicable to Manufacturing type of systems, I found it very relevant to apply the principle to solve the complex situation we were in.
We in software business talk about life cycles like Waterfall, Agile, Iterative etc. The principle of TOC can work in conjunction with any one of them. Let us look at the brief case study.
On 1st October 2009, we saw this project getting out of our hand. We brainstormed and brought major changes the way we managed the project. We looked at each element of project team. The team structure can be depicted as sequential block of related activities. Each block represented a processing station.
We noticed a lot of backlog, late working and low motivation at Integration station. UAT team, which was a Client team also, had a similar problem. The natural outcome was to define Goals for the project and structure the team around the defined goals. The goals were agreed as:
1. Improving throughput through the system.
2. Ensuring high quality of deliverables. It was thought to reduce UAT defects at least by 67%.
Besides the above goals, a working discipline was agreed to support the stated goals. Every station will work towards ensuring the utilization of critical stations ( Integration & Acceptance in this case) and the work allocation will be done to assist faster throughput and not ensuring higher utilization of the members in different stations. The work was structured in batches and batch movement across various stations was monitored and managed on above principles.
Implementing this discipline in the team faced resistance from both internal team members and the Client. A series of discussion were held with stakeholders and finally a concurrence from the customer was obtained for trying this out. We were confident to demonstrate the benefits within a week or so. This was used to make Client agree to watch the process for a fortnight.
After agreeing with the basic rules of the game, all team worked to support the goals. We carried through system of daily stand up call concentrating on three questions - what got done in last 24 hours, what are the plans for next 24 hours and what are the bottlenecks. We worked to solve the bottleneck.
The first batch with the new process was submitted on schedule. The result of the UAT was very encouraging and changed the morale of the team. People had renewed level of confidence. They were upbeat with the results. This changed the whole game. The theory was followed in word and spirit and in three months time the project got completed and accepted by the customer. Although we had a bad start, the excellent finish gave us excellent respectability from the client and great sense of achievement for all of us.
Software industry is gradually maturing. Time is getting apt for applying proven principles of manufacturing ( Factory Management Principles) in this maturing industry. TOC is one of them and I am upbeat with my experience on solving large complex project issues using this theory. It has worked well and can work with any life cycle selected for the project execution.
Thursday, June 10, 2010
A heuristic approach to Application Portfolio Management
1. INTRODUCTION
Globalization and the dilution of trade boundaries have forced industries to evaluate various options for cost-effective operations. Industries now face the challenge of channeling resources to meet organizational objectives in continuously changing environments. Information Technology plays a major role in such a dynamic business environment. However, with the advent of new technological tools and continuous advancement, the IT environment has become very complex.
Chief Information Officers (CIOs) regularly add new assets to their IT portfolio, making the portfolio more and more complex. In addition, they face the task of aligning business needs and IT assets. Cost consideration has becoming increasingly important. The challenge is to do more for less.
In such a dynamic situation, the management of the IT Portfolio has become an increasingly important and crucial task. An increasing number of CIOs are pursuing IT portfolio management as a tool to prioritize investment decisions, decide the location of various activities, evaluate the various assets with the value it delivers, and more.
Each asset in the portfolio is evaluated against parameters like cost of procurement, cost of managing, and indeed the cost of replacing the same. “Total cost of ownership” is seen in conjunction with the value delivered by the asset. Optimal management of assets leads to minimal TCO.
A study by Gartner states that, “Approximately 30 percent of the total cost of ownership during the life of an application is for its maintenance and management.” One can achieve a significant degree of cost reduction by maneuvering the costs associated with maintenance and management.
2. WHAT IS APPLICATION PORTFOLIO MANAGEMENT (APM)?
Portfolio management is the process of managing assets and investments in order to achieve desired organizational goals. The portfolio is a combination of assets that are expected to provide certain returns. It has risks associated with it. PM includes selecting a set of assets congruent with the set goal, managing the economic lifecycle of those assets, dynamically divesting and investing in different assets to optimize gains. In the IT context, the portfolio includes application software, hardware, infrastructure, resources, processes, and so on. While financial portfolio management has been in practice for many years, IT portfolio management is relatively new and gaining ground. An integrated framework that helps in investment, divestment, modifications, and movement of application assets has become a necessity to align business and IT goals of an enterprise.
Application Portfolio Management can be best described as:
• A "living program" that allows you to assess the applications in your portfolio, evaluate potential changes, and understand the risks and impact of these changes to the portfolio.
• A discipline and a set of tool that enables a CIO to respond to the pressures of managing an application portfolio.
• A framework helping in relating the total cost of ownership to revenue, identifying redundancies and gaps in current capabilities, pinpointing trouble spots, and highlighting opportunities to pursue sourcing alternatives.
3. WHY IS IT NEEDED?
An APM framework…
• Continuously monitors the environmental changes in business and keeps it optimal.
• Aligns business and IT objectives.
• Reduces portfolio complexity and creates a portfolio roadmap.
• Reduces the total cost of ownership.
4. AN APPROACH TO APM
The introduction of APM in an organization has to be phased balancing the costs, benefits, risks, and business objectives. The APM is a continuous process like a Financial Portfolio Management where the portfolio manager continuously watches the environmental changes and fine-tunes the portfolio for optimal gain.
The Application Portfolio Management necessarily requires a life cycle for effectiveness. The phases of the lifecycle are described hereunder:
4.1 Define Goals & Strategies
IT initiatives are meant to facilitate better business goal achievement. Business goals are defined for the overall organization. A top-down approach is recommended to create IT goals congruent with business goals. One of the options could be the use of Balance Score Card (BSC) developed by Kaplan and Norton. Once the IT goals are frozen, the same is broken into functional goals. This leads to a broad-level functional and technological implementation strategy.
Some key tasks are listed below:
• Identify relevant business Goals
• Identify IT goals and initiatives
• Map IT initiatives
• Cluster the applications on the basis of
o Functional
o Technology
• Evaluate alternatives strategy for clusters
• Finalize the strategy for each cluster
• Set goal for APM initiatives
4.2 Resource the initiative
Management sponsorship is a must to take the initiative forward. It is suggested that one must identify an owner for the initiative, get a budget approval, set improvement goals, and create a plan to complete the exercise. Some of the tasks during this phase are:
• Obtain management sponsorship
• Identify a lead to carry the initiative
• Get budget allocation
• Get Plan approval
4.3 Conduct an assessment
An analytical framework must be put in place to assess each application from the Maintain, Improve, and Retire perspective. The assessment is a combination of interviews with stakeholders and relevant data collection. The collected data is sanitized and analyzed using the framework. An index representing the ease of movement and value creation is established for each application. The set of applications are classified in different bands based on ease of movement, value creation, functional grouping, and technological grouping. A final sequence is arrived at by superimposing customer comfort level on the final analysis. The task sequence is listed hereunder:
• Portfolio analysis
• Model Building / Customization
• Analysis and computation
o Application Index
o Criticality, Volatility, Complexity indices
o Value Creation Index
• Evaluate applications and decide the strategy
4.3.1 Developing application indices
A detailed analysis in terms of criticality, complexity, value, cost, etc. is necessary to get an insight into the state of the application and conclude its future. Since the analysis is aimed at examining the application portfolio and improving the cost–value performance, an index is established to throw light on ease of movement.
Application index is a measure of moveability of the application. Higher the index, the more difficult it is to move. Developing the index helps in classifying applications in different bands and gets a relative assessment of application moveability.
4.3.2 Portfolio Analysis
Application portfolio analysis is the first step towards application outsourcing planning. It details:
• Application
• Technical Environment
• Functional Group
• Documentation Group
• Associated costs
The following table provides a high-level overview of the Portfolio Analysis phase:
Portfolio Analysis
Entry Criteria
1. Go ahead
Exit Criteria
1. Identification of application portfolio.
2. Determination of technical and functional grouping.
Methods and Tools
1. Data Collection—Forms/Questionnaire
2. Interviews
3. Data Summarization
Key Tasks
1. Establish a high-level plan.
2. Discuss the detailed approach.
3. Conduct interviews with application managers, key users, and IT directors.
4. Collect data from available records.
5. Identify functional group.
6. Identify technical grouping.
4.3.3 Model Building and customization
This phase helps in customizing the framework to suit specific requirements of the customer. The diagram depicts the base model, which is customized during this phase.
The following table provides a brief overview of Model Building and customization:
Model Building and customization
Entry Criteria
1. Attribute-wise application inventory.
2. Technological and functional grouping.
Exit Criteria
1. Definition of application attributes and its factors.
2. Model for application index.
Methods and Tools
1. Sum of position digit method.
Key Tasks
1. Identify significant factors affecting application outsourcing.
2. Define each factor as an index.
3. Assign weight to each application factor.
4.3.4 Analysis and computation
During this phase, significant factors are grouped together to develop various application indices. The data is checked/examined for range behavior, indices are computed, and normalization of indices is done to bring parity amongst the indices.
Analysis and computation
Entry Criteria
1. Application indices definition
Exit Criteria
1. Application index
2. Functional group
3. Technological group
Methods and Tools
1. Statistical analysis (distribution, range analysis)
2. Delphi techniques
Key Tasks
1. Establish the indices.
2. Normalize the application indices.
3. Compute composite application index.
4. Map Technological and functional grouping to each application.
5. Compute Documentation index.
Factors contributing to each index are identified along with the value range. Data cleansing and analysis is done to arrive at normalized indices. After developing various indices, the Delphi method is used to arrive at the Application Index and the Value Creation Index.
4.3.5 Studying Indices
The analysis of the indices gives real power to the framework. It helps to view the application portfolio from different angles and to arrive at conclusions. The following sections provide an overview of the different perspectives:
(i) Cost Vs Criticality
The criticality index for each application is a measure of the application’s criticality from the business standpoint. The quadrants of the Ansoff Matrix depict four possible situations.
Quadrant I: Low criticality and low cost: These applications will require further analysis before any recommendations are made.
Quadrant II: High on criticality and low on cost: These applications can be evaluated for retention.
Quadrant III: Low on criticality and high on cost: These applications are potential candidates for replacement.
Quadrant IV: High criticality and high cost: These applications should be examined for cost performance improvement.
(ii) Volatility Vs Criticality
Critical applications are the lifeline of an organization. The role of the CIO is to provide stable applications to the organization. The Ansoff Matrix of Volatility-Criticality helps to identify the application/application group to improve stability. This study leads to further analysis in terms of design improvement, platform rationalization, re-engineering, and so on.
Quadrant I: Low on criticality and low on volatility: These applications require more analysis for action.
Quadrant II: High on criticality and low on volatility: If there are no other compelling factors, these applications can be continued on an as-is basis. For example, if some applications from this group have the potential for savings by replacing or off-shoring them, they can be moved, or else they can be continued in their present state.
Quadrant III: Low on criticality and high on volatility: We do not have any application falling in this quadrant. Normally, these applications can be evaluated for retiring.
Quadrant IV: High on criticality and high on volatility: These applications need to be improved. The improvement should aim to reduce volatility. This could be possible by replacing or fixing the cause of volatility.
(iii) Analyzing Functional Group Complexity
The various functional group systems must be aligned with business objectives. The Complexity Index helps in identifying the most complex functional group using the Pareto analysis. The Complexity Index of each application is used to derive the Group Complexity Index through the Pareto analysis. This analysis provides an insight for group-wise BPR and re-engineering to reduce system complexity.
(iv) Gas Guzzler
Organizations have limited dollars to support application portfolios. Interestingly, all applications in the portfolio do not consume equal amount of dollars and follow the 20-80 rule. This analysis sheds light on what needs attention, what needs better control, and/or what applications need to be moved reduce overall maintenance cost.
4.4 Implement
Implementation is a crucial phase of APA frame work. A plan is developed and concurrence is obtained from stakeholders. It is recommended to have an implementation team, proper management oversight for implementation. Some of the tasks are:
• Finalize recommendations
• Discuss with stakeholders
• Present to management and obtain their concurrence
• Implement
4.5 Monitor & Control
Portfolio analysis is an ongoing work. Once the recommendations are implemented, there is a need to have periodic evaluation of the portfolio assets. It is recommended to align the periodic portfolio evaluation in the CIO’s KRA for success. Some select tasks shall be:
• Define appropriate Metrics
• Develop a score card
• Collect info, evaluate & monitor
• Realign the overall APM process
5. CONCLUSION
Application Portfolio Management is an important concept for a CIO. It is very helpful in integrating business goals with IT initiatives. There are tools available to practice in different space. However, without waiting for application of tools a beginning can be made to introduce the process and get a better understanding before one invests in the tool.
The heuristic model discussed in this paper is a great tool which can be practiced in an organization. A beginning can be made without any additional investment in APM tools.
There are always applications that consume a significant portion of support resources. An APM study revealed that the top 20 applications in an organization out of 120 accounted for 88% hours spent on maintenance. A differential strategy was suggested for these applications, which included better supervision, reassignment of key resources, and aligning some of the applications with the long-term road map of the enterprise. This helped in reducing the overall maintenance time.
The analysis can also help in identifying applications in different buckets like Maintain, Continue, Improve and Retire.
Globalization and the dilution of trade boundaries have forced industries to evaluate various options for cost-effective operations. Industries now face the challenge of channeling resources to meet organizational objectives in continuously changing environments. Information Technology plays a major role in such a dynamic business environment. However, with the advent of new technological tools and continuous advancement, the IT environment has become very complex.
Chief Information Officers (CIOs) regularly add new assets to their IT portfolio, making the portfolio more and more complex. In addition, they face the task of aligning business needs and IT assets. Cost consideration has becoming increasingly important. The challenge is to do more for less.
In such a dynamic situation, the management of the IT Portfolio has become an increasingly important and crucial task. An increasing number of CIOs are pursuing IT portfolio management as a tool to prioritize investment decisions, decide the location of various activities, evaluate the various assets with the value it delivers, and more.
Each asset in the portfolio is evaluated against parameters like cost of procurement, cost of managing, and indeed the cost of replacing the same. “Total cost of ownership” is seen in conjunction with the value delivered by the asset. Optimal management of assets leads to minimal TCO.
A study by Gartner states that, “Approximately 30 percent of the total cost of ownership during the life of an application is for its maintenance and management.” One can achieve a significant degree of cost reduction by maneuvering the costs associated with maintenance and management.
2. WHAT IS APPLICATION PORTFOLIO MANAGEMENT (APM)?
Portfolio management is the process of managing assets and investments in order to achieve desired organizational goals. The portfolio is a combination of assets that are expected to provide certain returns. It has risks associated with it. PM includes selecting a set of assets congruent with the set goal, managing the economic lifecycle of those assets, dynamically divesting and investing in different assets to optimize gains. In the IT context, the portfolio includes application software, hardware, infrastructure, resources, processes, and so on. While financial portfolio management has been in practice for many years, IT portfolio management is relatively new and gaining ground. An integrated framework that helps in investment, divestment, modifications, and movement of application assets has become a necessity to align business and IT goals of an enterprise.
Application Portfolio Management can be best described as:
• A "living program" that allows you to assess the applications in your portfolio, evaluate potential changes, and understand the risks and impact of these changes to the portfolio.
• A discipline and a set of tool that enables a CIO to respond to the pressures of managing an application portfolio.
• A framework helping in relating the total cost of ownership to revenue, identifying redundancies and gaps in current capabilities, pinpointing trouble spots, and highlighting opportunities to pursue sourcing alternatives.
3. WHY IS IT NEEDED?
An APM framework…
• Continuously monitors the environmental changes in business and keeps it optimal.
• Aligns business and IT objectives.
• Reduces portfolio complexity and creates a portfolio roadmap.
• Reduces the total cost of ownership.
4. AN APPROACH TO APM
The introduction of APM in an organization has to be phased balancing the costs, benefits, risks, and business objectives. The APM is a continuous process like a Financial Portfolio Management where the portfolio manager continuously watches the environmental changes and fine-tunes the portfolio for optimal gain.
The Application Portfolio Management necessarily requires a life cycle for effectiveness. The phases of the lifecycle are described hereunder:
4.1 Define Goals & Strategies
IT initiatives are meant to facilitate better business goal achievement. Business goals are defined for the overall organization. A top-down approach is recommended to create IT goals congruent with business goals. One of the options could be the use of Balance Score Card (BSC) developed by Kaplan and Norton. Once the IT goals are frozen, the same is broken into functional goals. This leads to a broad-level functional and technological implementation strategy.
Some key tasks are listed below:
• Identify relevant business Goals
• Identify IT goals and initiatives
• Map IT initiatives
• Cluster the applications on the basis of
o Functional
o Technology
• Evaluate alternatives strategy for clusters
• Finalize the strategy for each cluster
• Set goal for APM initiatives
4.2 Resource the initiative
Management sponsorship is a must to take the initiative forward. It is suggested that one must identify an owner for the initiative, get a budget approval, set improvement goals, and create a plan to complete the exercise. Some of the tasks during this phase are:
• Obtain management sponsorship
• Identify a lead to carry the initiative
• Get budget allocation
• Get Plan approval
4.3 Conduct an assessment
An analytical framework must be put in place to assess each application from the Maintain, Improve, and Retire perspective. The assessment is a combination of interviews with stakeholders and relevant data collection. The collected data is sanitized and analyzed using the framework. An index representing the ease of movement and value creation is established for each application. The set of applications are classified in different bands based on ease of movement, value creation, functional grouping, and technological grouping. A final sequence is arrived at by superimposing customer comfort level on the final analysis. The task sequence is listed hereunder:
• Portfolio analysis
• Model Building / Customization
• Analysis and computation
o Application Index
o Criticality, Volatility, Complexity indices
o Value Creation Index
• Evaluate applications and decide the strategy
4.3.1 Developing application indices
A detailed analysis in terms of criticality, complexity, value, cost, etc. is necessary to get an insight into the state of the application and conclude its future. Since the analysis is aimed at examining the application portfolio and improving the cost–value performance, an index is established to throw light on ease of movement.
Application index is a measure of moveability of the application. Higher the index, the more difficult it is to move. Developing the index helps in classifying applications in different bands and gets a relative assessment of application moveability.
4.3.2 Portfolio Analysis
Application portfolio analysis is the first step towards application outsourcing planning. It details:
• Application
• Technical Environment
• Functional Group
• Documentation Group
• Associated costs
The following table provides a high-level overview of the Portfolio Analysis phase:
Portfolio Analysis
Entry Criteria
1. Go ahead
Exit Criteria
1. Identification of application portfolio.
2. Determination of technical and functional grouping.
Methods and Tools
1. Data Collection—Forms/Questionnaire
2. Interviews
3. Data Summarization
Key Tasks
1. Establish a high-level plan.
2. Discuss the detailed approach.
3. Conduct interviews with application managers, key users, and IT directors.
4. Collect data from available records.
5. Identify functional group.
6. Identify technical grouping.
4.3.3 Model Building and customization
This phase helps in customizing the framework to suit specific requirements of the customer. The diagram depicts the base model, which is customized during this phase.
The following table provides a brief overview of Model Building and customization:
Model Building and customization
Entry Criteria
1. Attribute-wise application inventory.
2. Technological and functional grouping.
Exit Criteria
1. Definition of application attributes and its factors.
2. Model for application index.
Methods and Tools
1. Sum of position digit method.
Key Tasks
1. Identify significant factors affecting application outsourcing.
2. Define each factor as an index.
3. Assign weight to each application factor.
4.3.4 Analysis and computation
During this phase, significant factors are grouped together to develop various application indices. The data is checked/examined for range behavior, indices are computed, and normalization of indices is done to bring parity amongst the indices.
Analysis and computation
Entry Criteria
1. Application indices definition
Exit Criteria
1. Application index
2. Functional group
3. Technological group
Methods and Tools
1. Statistical analysis (distribution, range analysis)
2. Delphi techniques
Key Tasks
1. Establish the indices.
2. Normalize the application indices.
3. Compute composite application index.
4. Map Technological and functional grouping to each application.
5. Compute Documentation index.
Factors contributing to each index are identified along with the value range. Data cleansing and analysis is done to arrive at normalized indices. After developing various indices, the Delphi method is used to arrive at the Application Index and the Value Creation Index.
4.3.5 Studying Indices
The analysis of the indices gives real power to the framework. It helps to view the application portfolio from different angles and to arrive at conclusions. The following sections provide an overview of the different perspectives:
(i) Cost Vs Criticality
The criticality index for each application is a measure of the application’s criticality from the business standpoint. The quadrants of the Ansoff Matrix depict four possible situations.
Quadrant I: Low criticality and low cost: These applications will require further analysis before any recommendations are made.
Quadrant II: High on criticality and low on cost: These applications can be evaluated for retention.
Quadrant III: Low on criticality and high on cost: These applications are potential candidates for replacement.
Quadrant IV: High criticality and high cost: These applications should be examined for cost performance improvement.
(ii) Volatility Vs Criticality
Critical applications are the lifeline of an organization. The role of the CIO is to provide stable applications to the organization. The Ansoff Matrix of Volatility-Criticality helps to identify the application/application group to improve stability. This study leads to further analysis in terms of design improvement, platform rationalization, re-engineering, and so on.
Quadrant I: Low on criticality and low on volatility: These applications require more analysis for action.
Quadrant II: High on criticality and low on volatility: If there are no other compelling factors, these applications can be continued on an as-is basis. For example, if some applications from this group have the potential for savings by replacing or off-shoring them, they can be moved, or else they can be continued in their present state.
Quadrant III: Low on criticality and high on volatility: We do not have any application falling in this quadrant. Normally, these applications can be evaluated for retiring.
Quadrant IV: High on criticality and high on volatility: These applications need to be improved. The improvement should aim to reduce volatility. This could be possible by replacing or fixing the cause of volatility.
(iii) Analyzing Functional Group Complexity
The various functional group systems must be aligned with business objectives. The Complexity Index helps in identifying the most complex functional group using the Pareto analysis. The Complexity Index of each application is used to derive the Group Complexity Index through the Pareto analysis. This analysis provides an insight for group-wise BPR and re-engineering to reduce system complexity.
(iv) Gas Guzzler
Organizations have limited dollars to support application portfolios. Interestingly, all applications in the portfolio do not consume equal amount of dollars and follow the 20-80 rule. This analysis sheds light on what needs attention, what needs better control, and/or what applications need to be moved reduce overall maintenance cost.
4.4 Implement
Implementation is a crucial phase of APA frame work. A plan is developed and concurrence is obtained from stakeholders. It is recommended to have an implementation team, proper management oversight for implementation. Some of the tasks are:
• Finalize recommendations
• Discuss with stakeholders
• Present to management and obtain their concurrence
• Implement
4.5 Monitor & Control
Portfolio analysis is an ongoing work. Once the recommendations are implemented, there is a need to have periodic evaluation of the portfolio assets. It is recommended to align the periodic portfolio evaluation in the CIO’s KRA for success. Some select tasks shall be:
• Define appropriate Metrics
• Develop a score card
• Collect info, evaluate & monitor
• Realign the overall APM process
5. CONCLUSION
Application Portfolio Management is an important concept for a CIO. It is very helpful in integrating business goals with IT initiatives. There are tools available to practice in different space. However, without waiting for application of tools a beginning can be made to introduce the process and get a better understanding before one invests in the tool.
The heuristic model discussed in this paper is a great tool which can be practiced in an organization. A beginning can be made without any additional investment in APM tools.
There are always applications that consume a significant portion of support resources. An APM study revealed that the top 20 applications in an organization out of 120 accounted for 88% hours spent on maintenance. A differential strategy was suggested for these applications, which included better supervision, reassignment of key resources, and aligning some of the applications with the long-term road map of the enterprise. This helped in reducing the overall maintenance time.
The analysis can also help in identifying applications in different buckets like Maintain, Continue, Improve and Retire.
Thursday, May 27, 2010
Role of Project selection in building a successful company
I remember one of my Professor’s during my MBA days; once he gave us a powerful explanation on ‘Option of Choice’. During that time, one of the exams was close by. Typically students were used to the habit of answering five questions out of seven asked in the exam. Unlike other Professor’s, this professor was a little different and would never give options in the examination. When asked, “Father“, will we have any options this time? He replied, you will have a few of them. You can answer all 5, 4, 3, 2, 1 or don’t answer anyone. This short narration taught me the value of options in life. When I started working I found this short story to be of immense value. At every step of our lives we are confronted with several options. We may choose a few or let all go. The freedom of choice helps us to define the road ahead in our life.
Quarterly reporting has forced the company to just look one quarter ahead. The revenue targets and reporting to investors force company executives to dilute their freedom to choose an appropriate option. In hard times this becomes even more complex and the company executive tends to pick up “everything” which comes in front of them. This brings about serious consequences. In my long career path, I have come across such situations several times. May be dropping them could have lead the company to prosperity and growth.
I would like to share a case which was a result of wrong selection. The case demonstrates that how pseudo teaming happens when everyone in the management team says a yes. As such affirmative response gives a positive image to the participant. The whole team joins to cover up the failure and takes pride on great cooperation. The debate is whether such event is an example of great teaming up and co-operation or should this be viewed as team’s inability to arrive at the right decision in the beginning; this would have been profitable for the company and brings focus towards the goal.
The client was building a product which was running behind the schedule. The client had an urgency to expedite the work and meet release deadline. They wanted a vendor to take up some portion of their work and also help them in completing their work. The high level requirement was shared. The initial study of the requirement and sizing exercise indicated that it was not possible to complete in the given time frame. The client believed that if the vendor puts 3 qualified resources onsite, the job can be done. It was more of a feeling and did not have any back up of any scientific methods.
Sales team was constantly under the pressure to meet budget numbers and acquire new clients. Although the initial discussion on sizing was leading to a no-bid situation, they wanted to work with other operation division which agreed to work with them and complete the work in the given time frame. The result was simple and pleasing for everyone. A SOW was signed against the scientific estimation, based on a set of people who said yes to the unrealistic propositions. There was a sense of winning a new order which lead to a mood for celebration.
An onsite Project Manager was identified. She had working background in testing where as a substantial portion of the work was development. Meeting tight schedule was the key for success. Two developers were hired from the market. The three persons constituted the onsite project team.
It was hoped that on the success of this phase the subsequent phase moves offshore. The company was expected to give a fixed price bid for offshore portion. The offshore Manager was asked to help the Onsite project team. On first scrutiny of team’s capability and skill gap it was found that the team was not capable of delivering the contracted outcomes. This note was sent before the team assumed work onsite. The Manager controlling the activities along with sales believed that this was the best option in a given situation. The team went ahead with the onsite work. The activities went on for around 6 weeks. The outcome of this can be easily guessed by anyone. The client terminated the project. It was a LOSE-LOSE situation.
This event isn’t unusual - in any company. We all commit mistakes. It is important to learn from mistakes and not repeat the same in future. The success and failure depends on exercising the option of choice. Denis Waitley says;”Forget about the consequences of failure. Failure is only a temporary change in direction to set you straight for your next success". Choice always comes in life. Going on a right path helps to create a sound work culture, brings focus in operating teams and drives better results. Let us argue that management starts rejecting such opportunities. It will bring focus in sales team. They will start looking for right opportunities. Teaming up is very essential in today’s environment for success. Probably the team started defining the “Teaming up” in an inappropriate sense.
This short case tells us a lot. Few of the lessons are:
1. Requirement assessment is the key to project’s success and profitability. Even under pressure, compromising on basics may not lead to success. I think the proper understanding of the situation is important. We should also work with stretch goal.
2. Taking every piece of work is putting your company in a troubled position. It prohibits bringing focus and growth. Saying ‘NO’ requires courage and conviction for success.
3. Technical feasibility of doing work and risk assessment should be treated as separate items. Balance between risk and appetite to take the level of risk is essential.
4. Teaming is the key to success. Teaming compromising functional boundaries leads to failures and provides a pseudo teaming feeling.
5. Role of devil advocate is very important. This brings a culture of discussion and looking at all aspects of the opportunity before a decision is arrived. The hierarchy or prevailing culture may be a deterrent in creating a proper climate for devil advocate’s role. The leadership should provide appropriate climate for devil advocate. Their contribution in helping to take a sound decision cannot be undermined.Whether the projects are small sized or large sized, every project must bring about appreciation, intelligence and a good business sense. To achieve our goals we should have a well planned Project Selection Process.
Thursday, May 20, 2010
Delivering Quality
Software Development has gone through a lot of transformation over the last few decades. Many practices have evolved. A lot of metrics have been collected. Project Management software’s have been used to plan and track the project execution. Many new practices have come and gone by. New Practices keep on coming. A lot of change has happened in the lifecycle area. Agile is the BUZZ word at this point in time. The question is, has the industry delivered quality consistently? I am sure many one of us will come up with an answer “NO”.
There could be various reasons for not delivering “Quality” consistently. The industry has grown at astronomical pace. This has led to the lack of maturity in the practices. The industry will mature one day. The implementation of projects will become more predictable. What should we do in this transition phase – Maturing Software Industry? I have learnt a simple principle which I would like to share with you.
The software best practices are meant for delivering consistent quality. The principles are known to all. This is not a rocket- science. But most of us have struggled in implementing them successfully and thus couldn’t reap the benefits. I suggest here with a two phase formula for a quick result:
1. The Long term success & Consistency: The best answer would be obtained by following the best practices in requirement management, design, implementation, testing and deployment. I wonder if programmers shall ever be able to develop a set of bug free codes. If it happens then the tester communities will be unemployed. This certainly will impact sagging job market of a country like US and growing Job market of a country like India. Thanks to the effectiveness of Programmers, the testing job has been growing. The developers should continue trying hard for bug-free codes which would eventually lead to elimination of testing work. Think; if they code perfectly and implement all functionalities flawlessly, then at the crack of dawn our dreams shall come true. Practice for improvement will lead to better and better development and reduction of cost. Elimination of testing is still a farfetched thinking.
2. Deliver best to the customer in short term: Since the elimination of testing work or reducing the same to minimal is much more than a dream. We need to have some mechanism which produces better results. This may not be a very cost effective solution. But I have seen this helping win back the customer’s confidence. Unless we win customer’s confidence, work will not continue. Therefore, for point 1, – it is essential to keep going. The suggestion here is to divide the project team into Two teams
a. Development Team
b. Independent Test Team
The test team should be fully empowered and given independence. The team should report at a much higher level than the Project Manager. All testing best practices should be followed. I’m a witness to this and have seen this giving the best results. It helps in filtering the defects before it goes to customer. You have to incur additional cost to fix the bugs. But you are buying the customer’s confidence in the absence of best quality development. Unfortunately, many companies are doing this and striving for near flawless development. This is the right strategy to endure in today’s software industry.
I have noticed tremendous resistance by line managers to implement independent testing in each and every case. Such practices give a pseudo feeling of loss of authority. People tend to forget that “deferring problem” is not solving the problem. I have seen some techniques like Coaching; Training in testing, vigorously implementing this practice will help a lot. You may decide your own way to tread the path to success.
Create an Independent Test organization, carve it out from total project and implement. You will enjoy customer blessings. If you keep on doing point 1, you will continuously keep on improving profitability over the years.
Peter Drucker has rightly said, "The single most important thing to remember about any enterprise is that there are no results inside its walls. The result of a business is a Satisfied CUSTOMER."
This shall help in delivering Quality consistently.
There could be various reasons for not delivering “Quality” consistently. The industry has grown at astronomical pace. This has led to the lack of maturity in the practices. The industry will mature one day. The implementation of projects will become more predictable. What should we do in this transition phase – Maturing Software Industry? I have learnt a simple principle which I would like to share with you.
The software best practices are meant for delivering consistent quality. The principles are known to all. This is not a rocket- science. But most of us have struggled in implementing them successfully and thus couldn’t reap the benefits. I suggest here with a two phase formula for a quick result:
1. The Long term success & Consistency: The best answer would be obtained by following the best practices in requirement management, design, implementation, testing and deployment. I wonder if programmers shall ever be able to develop a set of bug free codes. If it happens then the tester communities will be unemployed. This certainly will impact sagging job market of a country like US and growing Job market of a country like India. Thanks to the effectiveness of Programmers, the testing job has been growing. The developers should continue trying hard for bug-free codes which would eventually lead to elimination of testing work. Think; if they code perfectly and implement all functionalities flawlessly, then at the crack of dawn our dreams shall come true. Practice for improvement will lead to better and better development and reduction of cost. Elimination of testing is still a farfetched thinking.
2. Deliver best to the customer in short term: Since the elimination of testing work or reducing the same to minimal is much more than a dream. We need to have some mechanism which produces better results. This may not be a very cost effective solution. But I have seen this helping win back the customer’s confidence. Unless we win customer’s confidence, work will not continue. Therefore, for point 1, – it is essential to keep going. The suggestion here is to divide the project team into Two teams
a. Development Team
b. Independent Test Team
The test team should be fully empowered and given independence. The team should report at a much higher level than the Project Manager. All testing best practices should be followed. I’m a witness to this and have seen this giving the best results. It helps in filtering the defects before it goes to customer. You have to incur additional cost to fix the bugs. But you are buying the customer’s confidence in the absence of best quality development. Unfortunately, many companies are doing this and striving for near flawless development. This is the right strategy to endure in today’s software industry.
I have noticed tremendous resistance by line managers to implement independent testing in each and every case. Such practices give a pseudo feeling of loss of authority. People tend to forget that “deferring problem” is not solving the problem. I have seen some techniques like Coaching; Training in testing, vigorously implementing this practice will help a lot. You may decide your own way to tread the path to success.
Create an Independent Test organization, carve it out from total project and implement. You will enjoy customer blessings. If you keep on doing point 1, you will continuously keep on improving profitability over the years.
Peter Drucker has rightly said, "The single most important thing to remember about any enterprise is that there are no results inside its walls. The result of a business is a Satisfied CUSTOMER."
This shall help in delivering Quality consistently.
Subscribe to:
Posts (Atom)