Many of us agree that IT projects are more error prone than any other project category. This is quite visible by the success rate for these projects. Among the IT projects, software development projects receive the lowest ranking as far as success rate is concerned.
Even if some software development projects do receive the “distinction” of being successful, they end up being a burden in terms of high maintenance staff salaries and excessive payments for changes/improvements. After two to three years, these so called successful software development projects end up being a part of your IT data backup graveyard.
Why there is such a case for software development projects even though most of the times they cost a lot less than construction and manufacturing projects. One basic difference between the two types of project categories is the success criteria.
In construction and manufacturing projects, you surely can quantify the success criteria of your project e.g. a manufacturing plant improvement that will increase the throughput of plant by so and so. But is it the case for software development projects?? Probably not; because in case of software development, both the client and the solution provider are at fault for not “quantifying” the success criteria of the software development project e.g. when developing a human resource system, the client is stressing that he wants to improve to human resource department efficiency and the solution provider is claiming that by having the state of the art technology the efficiency of the human resource department will be improved.
Now what does the term “improvement” means is not clear until you are in the post deployment phase of your software development project. At this stage the client will start saying “previously it took three days to process hundred applications and now it’s taking more than ten days to do the same” or “our payroll processing is taking three days whereas previously it took just one day”. Would it be nice if these objective statements were known and agreed in advance at the start of the project? Would solution provider and its team be more focused once they had this information at the start of the project?
So it is important that you quantify your software project’s success criteria to avoid being part of the long list of un-successful projects.
Showing posts with label Six Sigma. Show all posts
Showing posts with label Six Sigma. Show all posts
Monday, March 24, 2008
Saturday, January 5, 2008
Developing an Enterprise Resource Planning system using Six Sigma
Six Sigma is characterized by DMAIC (Define, Measure, Analyze, Improve and Control) approach. DMAIC refers to a data-driven quality strategy for improving processes. The steps defined by DMAIC can also serve as a guideline for developing an effective ERP system of an organization. As organizations are big in terms of their processes and sub-processes so it is important to realize that improvements will not come overnight and it require vision, and active top down leadership, to maximize their impact.
The process steps can be further elaborated as:
I) Define primary stakeholders, their Critical to Quality (CTQ) issues, and the core business processes and sub processes involved. It requires capturing the requirements and expectations of these stakeholders from an ERP system. Prioritizing activities is important as resource limitations might restrict the team to work on all the core business processes in parallel. It is also important to define the processes to be improved by mapping the process flow so that As Is scenario can be captured.
II) Measure the performance of the core business processes and sub processes involved. Here process priorities established in the Define phase must be observed. This phase requires developing a data collection plan for each individual process and sub process. We may have to collect data from different sources to determine types of defects. A good starting point would be to identify the Key Performance Indicators (KPI) for each process with respect to its primary stakeholders. Finally we can compare our findings with the primary stakeholder requirements and expectations to determine the shortfall.
III) Analyze the data collected and process map to determine root causes of defects and opportunities for improvement. By doing this we can Identify gaps between current performance and goal performance. Many a times we can identify more than one area for improvement so it is important to prioritize opportunities. Those opportunities which are not selected for improvement in the 1st phase can be selected at a later stage. During this phase we should also identify sources of variation.
IV) Improve the target processes and sub processes by designing and implementing creative solutions to fix and prevent problems. This can be achieved by adding a new module(s)/sub module(s) or changing existing module(s)/sub module(s) in the ERP system. At times there is no need to introduce technology as the desired results can be achieved by only altering the flow within a particular process or sub process. So it is important to get to the root cause of the problem and then identify ways to fix that problem.
V) Control the improvements to keep the processes and sub processes on the new course. It will also prevent the concerned staff reverting back to the "old way" of doing things. It requires the development, documentation and implementation of an ongoing monitoring plan. We also need to institutionalize the improvements through the modification of systems and structures (staffing, training, incentives).
In the end it is important to realize that our goal should be to achieve results not to implement any technology or software.
The process steps can be further elaborated as:
I) Define primary stakeholders, their Critical to Quality (CTQ) issues, and the core business processes and sub processes involved. It requires capturing the requirements and expectations of these stakeholders from an ERP system. Prioritizing activities is important as resource limitations might restrict the team to work on all the core business processes in parallel. It is also important to define the processes to be improved by mapping the process flow so that As Is scenario can be captured.
II) Measure the performance of the core business processes and sub processes involved. Here process priorities established in the Define phase must be observed. This phase requires developing a data collection plan for each individual process and sub process. We may have to collect data from different sources to determine types of defects. A good starting point would be to identify the Key Performance Indicators (KPI) for each process with respect to its primary stakeholders. Finally we can compare our findings with the primary stakeholder requirements and expectations to determine the shortfall.
III) Analyze the data collected and process map to determine root causes of defects and opportunities for improvement. By doing this we can Identify gaps between current performance and goal performance. Many a times we can identify more than one area for improvement so it is important to prioritize opportunities. Those opportunities which are not selected for improvement in the 1st phase can be selected at a later stage. During this phase we should also identify sources of variation.
IV) Improve the target processes and sub processes by designing and implementing creative solutions to fix and prevent problems. This can be achieved by adding a new module(s)/sub module(s) or changing existing module(s)/sub module(s) in the ERP system. At times there is no need to introduce technology as the desired results can be achieved by only altering the flow within a particular process or sub process. So it is important to get to the root cause of the problem and then identify ways to fix that problem.
V) Control the improvements to keep the processes and sub processes on the new course. It will also prevent the concerned staff reverting back to the "old way" of doing things. It requires the development, documentation and implementation of an ongoing monitoring plan. We also need to institutionalize the improvements through the modification of systems and structures (staffing, training, incentives).
In the end it is important to realize that our goal should be to achieve results not to implement any technology or software.
Reference: www.isixsigma.com
Subscribe to:
Posts (Atom)
