Where should employee training fall into the project life cycle?

Question

Where should employee training/reinforcement of new skills and techniques fall into the project life cycle? Is anyone able to find any studies conducted about how the end product is affected resulted if training is done on the production code during development as opposed to conducted between projects on non-production code.

My team just finished a few releases of different product variations. We now have some lull before our cycle picks back up. Being the team lead, I gave the team members an assignment to re-write an application (one used to gauge prospective employees) using things they've learned since joining the team. Things expected to see was use of dependency injection, unit testable code, and use of the MVVM pattern (a C# WPF design pattern).

My supervisor found out and didn't think this was the right thing to do with this down time. He believes that employees should learn the above things on production code/products to be shipped and that any additional learning and such should be done on their own time.

I do see the business perspective, but we currently have a product that we are about to redo from scratch because we employed this way of thinking in the past. I don't think we should do this, as that produces code that is hard to maintain and is usually buggy.

Did I make the right call for this lull or is there something better to do with the time? I was unsure what to search for and any studies conducted would be greatly appreciated.

Answer 1

In my view, formal training has no place whatsoever in a project life cycle. None. Projects are, by definition, discrete pieces of work having a finite time period and finite resources. No project dollars should be invested in formal learning of any project team members.

Informal learning occurs as a consequence of doing work. Training on the job of a newer team member is normal and project dollars will go towards that; however, work is still progressing during that time even when some rework needs to occur.

Other types of sanctioned project training would be for specific project type things that have to be transferred to the team. This is so the team will know how to operate within the project context but also to train something that cannot reasonably be found in the general resource pool.

Otherwise, the buyer of a project should not be on the hook to spend their money to train people who are only associated with his product for a specific period of time. That's 100% inappropriate.

My views on this subject are unpopular, I know.

Answer 2

While there might be a theoretical 'best practice', in reality it depends in large part on what your organization values. Even the decision to go ahead and assign a new project to the team rather than 'consulting'/'wasting the time of' your supervisor could be seen as a bad/good thing.

Has your supervisor been apprised of the costs of technical debts? If so, that's something that definitely needs to be done - not just for things like this, but for new development as well. If executives don't know the cost of technical debt, then they cannot make informed prioritization decisions regarding technical debt. If they do know the cost of technical debt, and they tell you to work on something else, then you should listen to them unless you have some cause to believe you understand what the priorities should be better than your superiors. In which case, you have bigger problems.

Answer 3

Training is a continuous process. Hence, an informal training takes place on every single aspect of process. In case of formal training one need to follow the company or project guidelines.

Or else the best way could be PMI/TSAT etc. to identify training need.