|BACK | Key Success Factors | IT for Business | people issues in IT | other articles on IT | My IT Strategy | Download articles|
|Read Comments Submit Comments|
From Bench to Centre of Excellence
Summary: This is my real story of getting extra-ordinary performance from ordinary people. A relatively inexperienced team sitting on the bench (unassigned developers who have no live projects and are waiting for new projects/ orders to arrive) gave birth to a Centre of Excellence of an emerging technology.
The year was 2001 end or 2002 beginning - the period of the first e-commerce boom. I was part of the newly set up e-commerce team of a SEI CMM Level 5 company. Apart from the role of a Project Director for web based projects covering all technologies, I had a secondary role as a Practice Head for Microsoft Technologies.
Microsoft .Net (pronounced dotNet) was the new technology on the horizon and the concepts of web-services (which were new in the web space) looked very promising. .Net was in beta stage. I felt it was my responsibility to pro-actively create the skills and the expertise in-house well before the final release of the technology. I had a team strength of about 150. Some were deputed on projects abroad, some were in project teams doing development in India. As used to happen quite often, there was a pool of unassigned developers/team leader who were on the bench (waiting for projects). Bench is a term used in software companies to refer to people who are not assigned to any project when there are not enough projects to keep all the developers busy. The people who have no projects on hand and are waiting for new orders and new projects to materialise are said to be sitting on the "bench".
Having worked in as CIO in manufacturing companies prior to joining this export oriented software unit, I was always playing with the idea of using these idle resources productively for developing and implementing solutions for internal use. In in-house IT set-ups of manufacturing companies, I was used to working with very limited manpower resources and I just could not see pools of resources sitting idle on the bench. There was no separate staff for in-house solutions in my company. I could kill two birds with one stone if I used my bench staff to develop simple solutions for internal use while learning new Microsoft .Net technology. Luckily there was a team leader also on the bench, having about 6 years' experience, though he had never led a project before. I made him responsible as a leader of the team. The rest of the persons on the bench had from zero to two years of experience.
When I communicated my desire
that I wanted all of them to learn .Net, they started reading. I told
them I did not want them to just read and get theoretical knowledge. I
made my objectives very clear. I asked them to think of a project for
themselves which will use the strengths of .Net and web services
technology, and possibly could be used internally to automate some
I put down the desirable qualities / attributes of the project they were to identify:
Preferably the project should be a real life application which could be used in-house by our company to improve processes and would thus benefit the company when implemented. This would give double benefits. Of course the company would benefit due to automated processes when implemented, but the team would also get experience of implementing, supporting and sustaining an application.
It should use the concept of web services.
It should have B2B (business-to-business) concepts using some newly released Microsoft products.
If the solution developed could not be used in-house, it should be realistic enough that it can be showcased as a prototype if not a product.
In spite of several reminders to all of them and the team lead to brainstorm and come out with an idea for the project, they could not think of any. I kept on pestering and reminding the leader, asking him if they had thought of a project. Finally one day, tired of my coaxing, they decided to lock themselves in a room for brainstorming and not come out till they had found an answer.
Luckily it worked and they came to me with a suggestion. It satisfied 80% of my criteria that I had set and I said I will accept that. The idea they came out was of an excellent prototype, which may not have been implemented immediately in the company, but could prove to be a very good marketing tool to showcase our expertise in .Net and web-services.
I asked the team leader to
make his own schedule, set a target completion date and get on with the
project. He set quite an aggressive schedule, I thought: flat 20 days
which was aggressive looking at the complexity of the project and
looking at the fact that there was no prior knowledge of this new
technology. At the same time it was a schedule which would push them in
a positive manner to achieve the target.
There were ample challenges. Apart from the fact that the team was relatively inexperienced, not to mention the obvious lack of prior knowledge of .Net, problems were added because the technology was in beta stage and there were very few books. There was little on-line documentation and few forums, but not enough expertise outside that you could find solutions through forums. Self learning and experimenting was the only way.
In such a scenario the team adopted a practice of writing to the few authors of the few books that were available. I remember there was one problem they faced where even the author they had written to had thrown up his hands and could not find a solution. My team worked relentlessly on the problem, found a solution and communicated it back to the author. The author was ecstatic.
There was very little
interference in the project and the team lead was given abundant
freedom and flexibility. The team finished the project dot on time. I
not only had a team well trained on an emerging technology, I had a
prototype for my marketing team to start marketing our .Net
capabilities. The Managing Director of the company was so excited when
he saw the prototype that he had made up his mind to more closely
Microsoft for .Net.
The team got good confidence
in learning new technology through self learning and of course the
confidence to train others and take up projects in the new technology.
The team leader
was ready and in high spirits to take up a real life client
project. The company had a prototype to showcase the
capability in .Net. A seed for the COE was sown.
Ordinary people can do extraordinary things given the right freedom, trust and motivation.
Even a raw team can give excellent results given the right conditions and motivation
Nothing is so difficult to learn and achieve.
Even youngsters with low experience can do a good job. You only need to trust them and assign them a task.
You do not need special people to do special things.
Brainstorming in a closed room can give good results
Managers need to have the courage to take risk. Often it is not because the staff is not skilled, but the manager is not capable to take the risk.
It is often due to manager's lack of risk taking ability that we do not get the best out of people (or people do not perform to their potential) and not because of the potential of the subordinates
Managers can restrict the creativity of the subordinates because of their fear that they may fail.
At the same time managers themselves need to be given enough freedom when they are experimenting with new technology, otherwise they are over-cautious and will not take risk. If I had put too much pressure to succeed, the manager would not be ready to take risk.
For New technology projects stiff targets enforced on the team do not work. You need to give just the right freedom to the manager. Moreover he should have the confidence that he is not going to be hanged if he fails. They will take risk if he is assured that you are part of the team to take ownership for failure - "Let us all try - if we succeed, we all succeed and if we fail, we all fail."
Experts can be created. The problem is not of lack of talent but lack of trust on the part of the managers.
Homecomments powered by Disqus. comments powered by Disqus