There are different methods of cross training, and I'd be interested to know if others agree with my version.
The premise of cross training is that people can jump in at any moment to help out. It can reduce the need for redundant staff. It can relieve pressure when one project gets behind.
And I'm all for it.
In my version of cross training, there is a basic expertise that each person has, with declining expertise on other projects. Think of the skills checklist that you sometimes have to fill out for job applications. You create a scorecard for everyone. This allows you to identify gaps in training and plan for future cross training. And it becomes very valuable during scheduling.
With cross training, there must be an element of training, which is why when scheduling and planning cross training, someone must be training and someone must be learning. They must be on the same project together. Now, training can have several definitions. In this case, the person learning should be spending time observing and asking questions of the expert as he or she performs the job. That person then has specific tasks to perform on the project. In turn, the expert doing the training needs to be able to fill out the scorecard at the end of the project, observing how much has been learned and how valuable the person will be next time.
Finally, to ensure success, there must be some non-overlap in projects. If this cannot happen, then you can't really shift resources between projects without jeopardizing the schedule or the training.
Friday, July 18, 2008
Friday, July 11, 2008
Applying Standards in Small Organizations
I am a proponent of using good process when developing projects. I am NOT a proponent of process for process' sake, however. So, when I've had the opportunity to work in smaller groups, I am confronted with decisions on how much process is feasible. Usually, when I mention a standard, I get one of two reactions. Either someone is pro-Six Sigma, CMMi, or another specific standard, and wants to apply it all now. Or, I hear that there is nothing in the budget, and anyway, process would slow us down. But so many startups run like the wind to develop products, only to find things in a big mess as they grow. It would be more efficient to put a bit of process in at the start. What to do?
Well, ISO has acknowledged this and is working with a number of other standards bodies to develop standards for what they call "Very Small Enterprises (VSEs)". The name of the group is ISO/IEC NP TR 29110. They are looking at what Latin America has done.
In Latin America, they are already using a model called MoProSoft for certification that looks promising. In the United States, any organization under 50 is considered a small enterprise, but in Latin America, it is more typical to find companies from 1-10 - the definition for VSEs. Because most of these companies were working with governmental bodies, they needed to prove certification, in much the same way as in the United States - where government contract companies are typically bigger. Having gotten the jump on creating these smaller processes, they can be used as a model for other VSEs interested in implementing process.
Up until now, I have found that in order to use standards in small enterprises, it was necessary to take parts of standards and use them as guidelines. This has worked well, and turns CMMi a bit on its head. Instead of starting with an organization of Level zero, and improve, you lay the groundwork using building blocks of known standards. Both CMMi and Six Sigma devotees assume that in the beginning there was no process. But there can be. Simple processes can be implemented just to be able to recreate a build, or track the testing. Utilize simple analyses of the last release to learn from it. By putting building blocks in place in the beginning, transition is easier as you grow.
So I will be watching to see if the new standards for VSEs can be adapted to startups that may grow. If so, we will be able to apply VSE standards for smaller organizations. If the organizations grow, the transition to standards for larger organizations will become easier.
Well, ISO has acknowledged this and is working with a number of other standards bodies to develop standards for what they call "Very Small Enterprises (VSEs)". The name of the group is ISO/IEC NP TR 29110. They are looking at what Latin America has done.
In Latin America, they are already using a model called MoProSoft for certification that looks promising. In the United States, any organization under 50 is considered a small enterprise, but in Latin America, it is more typical to find companies from 1-10 - the definition for VSEs. Because most of these companies were working with governmental bodies, they needed to prove certification, in much the same way as in the United States - where government contract companies are typically bigger. Having gotten the jump on creating these smaller processes, they can be used as a model for other VSEs interested in implementing process.
Up until now, I have found that in order to use standards in small enterprises, it was necessary to take parts of standards and use them as guidelines. This has worked well, and turns CMMi a bit on its head. Instead of starting with an organization of Level zero, and improve, you lay the groundwork using building blocks of known standards. Both CMMi and Six Sigma devotees assume that in the beginning there was no process. But there can be. Simple processes can be implemented just to be able to recreate a build, or track the testing. Utilize simple analyses of the last release to learn from it. By putting building blocks in place in the beginning, transition is easier as you grow.
So I will be watching to see if the new standards for VSEs can be adapted to startups that may grow. If so, we will be able to apply VSE standards for smaller organizations. If the organizations grow, the transition to standards for larger organizations will become easier.
Subscribe to:
Posts (Atom)