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.
Monday, March 24, 2008
Monday, February 4, 2008
Project “EVIL” Wish List
Having a wish list in your project is a common phenomenon. Everybody wants more good things in the project with fewer resources and in a short span of time.
There is no clear cut difference between wish list and necessary changes. Generally wish list can be characterized as something which does not look harmful at the start and the project manager or his/her team thinks that they can accommodate the request without suffering any delay. On the other hand, Change requests means something that will surely affect your project. When you are working on projects where funds are not coming from your own organization’s pocket, then change request can be a very good source of income.
For any project, it’s up to the project manager that how he/she conceives the wish list. In many organizations (with very few exceptions) saying a “NO” to a stakeholder wish is like putting up your resignation. So people are always in an “Accepting Mode” i.e. any wish that comes from a stakeholder is welcome or in Urdu “sir-e-tasleem kham”.
What people don’t realize is that this attitude is adversely affecting your project. Many a time this attitude results when the project manager is working simultaneously on projects and operations (like handling a portion or complete human resource department) and he/she is unable to distinguish the meaning and consequences of wish list in these two different work scenarios.
In projects (as you have scope, cost, resource, quality and time constraints) wish lists tend to have a long term impact on the health of any given project and you don’t realize the impact until or after execution phase of the project and when you do realize the impact, its very hard to trace back to the exact wish list; at the end its bad project management on your part and good critical assessment on stakeholder part.
In operations you do have the flexibility as far as triple constraints are concerned and it’s comparatively easy to evaluate the impact in early stages.
So it is better to say one “NO” than to face one hundred embarrassments.
There is no clear cut difference between wish list and necessary changes. Generally wish list can be characterized as something which does not look harmful at the start and the project manager or his/her team thinks that they can accommodate the request without suffering any delay. On the other hand, Change requests means something that will surely affect your project. When you are working on projects where funds are not coming from your own organization’s pocket, then change request can be a very good source of income.
For any project, it’s up to the project manager that how he/she conceives the wish list. In many organizations (with very few exceptions) saying a “NO” to a stakeholder wish is like putting up your resignation. So people are always in an “Accepting Mode” i.e. any wish that comes from a stakeholder is welcome or in Urdu “sir-e-tasleem kham”.
What people don’t realize is that this attitude is adversely affecting your project. Many a time this attitude results when the project manager is working simultaneously on projects and operations (like handling a portion or complete human resource department) and he/she is unable to distinguish the meaning and consequences of wish list in these two different work scenarios.
In projects (as you have scope, cost, resource, quality and time constraints) wish lists tend to have a long term impact on the health of any given project and you don’t realize the impact until or after execution phase of the project and when you do realize the impact, its very hard to trace back to the exact wish list; at the end its bad project management on your part and good critical assessment on stakeholder part.
In operations you do have the flexibility as far as triple constraints are concerned and it’s comparatively easy to evaluate the impact in early stages.
So it is better to say one “NO” than to face one hundred embarrassments.
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
Monday, December 3, 2007
Management reporting in the developing countries
In the developing countries, the usages of computerized database management software are increasing in every day corporate life. More and more companies are trying to manage their data electronically. MRP, MRP II, ERP, etc… are the buzzword in the corporate circle of the developing countries. With the introduction of these applications, the amount of information available for analysis is growing exponentially but what is not growing is the style of reporting and we are still using the old “static” style of reporting i.e. somebody (typically an IT person) develop the reports and these reports are presented to the top management for review and decision making. Even if the reporting is available “online” the kind of reports available still depends on the capability of your technical staff. So if he/she e.g. understands marketing then he/she can give something which can be close to what the marketing team is expecting and if he/she does not understand marketing then… good luck!
What is missing is that the functional departments like Finance, Marketing, Human Resources, etc… are keeping the reporting at a safe distance. They don’t want to involve themselves in reporting as they think it’s not their job and someone in the IT department should be doing this. But they should realize that it’s their data and they are the one who should have the first right to dice and slice the information. Now days the reporting software are so user friendly that you don’t even have to acquire formal training to use them and there is so much help available on the internet in the form of articles, tutorials and forums that you can even surprise your own IT department (because these are the sources from which they are getting the information). Of course you would need the support from the top management otherwise all your efforts could go in vain. The top management should also realize that they need to arm their front line resources with the tools to support proactive decision making.
What is missing is that the functional departments like Finance, Marketing, Human Resources, etc… are keeping the reporting at a safe distance. They don’t want to involve themselves in reporting as they think it’s not their job and someone in the IT department should be doing this. But they should realize that it’s their data and they are the one who should have the first right to dice and slice the information. Now days the reporting software are so user friendly that you don’t even have to acquire formal training to use them and there is so much help available on the internet in the form of articles, tutorials and forums that you can even surprise your own IT department (because these are the sources from which they are getting the information). Of course you would need the support from the top management otherwise all your efforts could go in vain. The top management should also realize that they need to arm their front line resources with the tools to support proactive decision making.
Thursday, November 15, 2007
Going through your resignation notice
Most of us come to this stage during their career where they are serving the notice period. The notice period duration tends to vary starting from 0 days to 30 days (in some case it even exceeds 30 days). If you are serving a standard thirty day notice then it can be divided into two major parts.
a. One where you are handing over your tasks;
b. And second where you are looking forward to your new job
The first part can be very busy depending upon the responsibilities or projects that you have with you at time it means spending late hours in the office to hand over your duties and the second part… well it can be very irritating.
Because you have already assigned your tasks to someone else and now you have nothing to do. Higher management will not involve you in key decisions and projects; your initiative fuel tank is almost empty. This is the time where you realize how long a single day in the office can be. Here you cannot leave the office because the management wants you to be there as “some” important tasks may require your input. In some cases even the charming internet browsing does have the same zest.
If you are serving a notice period for a week or two then you will be very lucky to avoid the second part of the notice period.
a. One where you are handing over your tasks;
b. And second where you are looking forward to your new job
The first part can be very busy depending upon the responsibilities or projects that you have with you at time it means spending late hours in the office to hand over your duties and the second part… well it can be very irritating.
Because you have already assigned your tasks to someone else and now you have nothing to do. Higher management will not involve you in key decisions and projects; your initiative fuel tank is almost empty. This is the time where you realize how long a single day in the office can be. Here you cannot leave the office because the management wants you to be there as “some” important tasks may require your input. In some cases even the charming internet browsing does have the same zest.
If you are serving a notice period for a week or two then you will be very lucky to avoid the second part of the notice period.
Tuesday, October 30, 2007
Hiring relatives… the downside for the HR
When it comes to hiring relatives, there are a lot of advantages e.g. you don’t need to do extensive background and security checks, you get a person who already knows about your company and is mentally ready to accept the challenge. These people also get trained quickly because they are getting the best training from their relative who has already spent 2-3 or more years in that job.
But there are certain arguments which suggest that hiring relatives is not a good option:
1. People tend to cover the mistakes made by their relatives during the job. So you might see a situation where the deficiencies in resources are exposed when his/her relative go on a long leave.
2. If one resource is under performing then you are not in a position to launch the firing orders.
3. If there is an off the job disagreement between the relatives then that will adversely affect their on job relationships.
4. Often when a relative is leaving the company he/she has the magical influence to take the other resource with him/her.
So the option is yours!
But there are certain arguments which suggest that hiring relatives is not a good option:
1. People tend to cover the mistakes made by their relatives during the job. So you might see a situation where the deficiencies in resources are exposed when his/her relative go on a long leave.
2. If one resource is under performing then you are not in a position to launch the firing orders.
3. If there is an off the job disagreement between the relatives then that will adversely affect their on job relationships.
4. Often when a relative is leaving the company he/she has the magical influence to take the other resource with him/her.
So the option is yours!
Monday, October 29, 2007
“IT” is all about empowerment for SME
The word IT can be defined as "the study, design, development, implementation, support or management of computer-based information systems, particularly software applications and computer hardware (ITAA)” and now days the word IT is being replaced with ICT (Information and Communication Technology).
Whenever you heard these words you start thinking high tech people with lots of gadgets up their sleeves. In a typical SME (small and medium enterprise) environment these people are untouchable. They have the financial backing even in tough economic situations and total management support. They always suggest state of the art software and hardware which in their perspective will improve the business processes and will add value towards higher customer satisfaction.
The downside is that other “non IT” staff will start resisting any implementation suggested by the IT department. Even If does add some value they will start thinking that it’s not in their best of interest, and add the fear of loosing your job to a machine, it certainly blocks the improvements which can come due to presence of a proper information system.
How can we avoid this… simple! Empower your employee.
How… well this is a bit tricky question and will depend from situation to situation. In some SME you don’t even need a full fledge information system if we just train the staff to start “using” the applications they are already working with. Just to quote a personal example, in my company (dealing with accounting) there is extensive use of Microsoft Excel and the main stream resources that we have are all accountants and they use Microsoft Excel more than 60-70% of the time.
Now if we propose a new accounting system with all the management backing they will still revert back to Microsoft Excel in one way or the other. The best option here is to train the resources how to effectively use Microsoft Excel. One can really add value to this training by starting with Lean thinking and then training resources in MS Excel and asking them to apply and eliminate any waste which they see in their current workings.
I have seen companies having high tech applications but there staff still prefer to use the simple spread sheet application which they learnt 5 years back.
Whenever you heard these words you start thinking high tech people with lots of gadgets up their sleeves. In a typical SME (small and medium enterprise) environment these people are untouchable. They have the financial backing even in tough economic situations and total management support. They always suggest state of the art software and hardware which in their perspective will improve the business processes and will add value towards higher customer satisfaction.
The downside is that other “non IT” staff will start resisting any implementation suggested by the IT department. Even If does add some value they will start thinking that it’s not in their best of interest, and add the fear of loosing your job to a machine, it certainly blocks the improvements which can come due to presence of a proper information system.
How can we avoid this… simple! Empower your employee.
How… well this is a bit tricky question and will depend from situation to situation. In some SME you don’t even need a full fledge information system if we just train the staff to start “using” the applications they are already working with. Just to quote a personal example, in my company (dealing with accounting) there is extensive use of Microsoft Excel and the main stream resources that we have are all accountants and they use Microsoft Excel more than 60-70% of the time.
Now if we propose a new accounting system with all the management backing they will still revert back to Microsoft Excel in one way or the other. The best option here is to train the resources how to effectively use Microsoft Excel. One can really add value to this training by starting with Lean thinking and then training resources in MS Excel and asking them to apply and eliminate any waste which they see in their current workings.
I have seen companies having high tech applications but there staff still prefer to use the simple spread sheet application which they learnt 5 years back.
Subscribe to:
Posts (Atom)
