• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
 

Vimal kumarkhanna

on

  • 374 views

 

Statistics

Views

Total Views
374
Views on SlideShare
374
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Vimal kumarkhanna Vimal kumarkhanna Document Transcript

    • 1 of 9 Managing Small Teams – Look beyond Process Simplification Vimal Kumar Khanna Abstract Managing large projects/teams is a complex problem. Hence, a significant amount of published work is focused on addressing challenges in managing large projects/teams. However, a number of projects, both in large and small companies, involve managing small teams – like most projects in small companies/startups; pilot projects; rookie managers being initially assigned small projects even in large companies; etc. Although, managing small teams seems easy but actually it presents a number of unique challenges, which are immensely different from challenges in managing large teams. However, most of the published work on managing small teams/projects addresses only the issue of simplifying project management processes. A major issue not being sufficiently addressed is meeting challenges in managing the “human aspect” – deciding manager/team members’ roles based on their strengths; building their skills through training/mentoring; motivating them; managing their growth aspirations; managing the significant impact of attrition on small teams; etc. This paper explores such challenges in managing small teams and suggests solutions. We consider the cases of managing small teams both in large organisations and in small companies/startups. We present approaches to be adopted both in product development and services projects. The work is based on experiences of managing small teams in global software companies like Novell, Cabletron, QLogic, Atheros, Mindteck, etc. Keywords: Small team, small project, pilot project. 1. Introduction It is a known fact that management of large projects/teams is quite complex and presents many challenges. Hence, significant amount of published work addresses this aspect. However, a number of projects in large/small companies involve managing small teams – - Most projects in small companies/startups where overall company team size itself is small - Pilot projects, even in large companies - Rookie managers being initially assigned small projects, etc. It should not be assumed that, unlike managing large teams, managing small teams is easy. Small teams present a number of unique management challenges, which are immensely different from challenges in managing large teams.
    • 2 of 9 Most of the published work on managing small projects/teams focuses on need for simplifying management processes. However, simplified processes alone cannot ensure success of projects since it is the team members who finally have to deliver using these processes. Hence, in this paper we would present techniques to successfully lead, train/mentor, motivate and meet aspirations of the manager/team members of small teams. The paper is based on experiences of managing small teams in leading global software organisations – large companies, small companies/startups, product development and services companies – like Novell, Cabletron, QLogic, Atheros, Mindteck, etc. We are considering maximum team size of eight members, with complete team directly reporting to the manager. We start by discussing the Related Work. We then discuss major challenges in managing small teams and suggest solutions to address them – experience/skills/training requirements for managers; scientific method for deciding multiple roles for lightly-loaded managers; techniques to motivate team members despite constraints imposed by small team size; and mitigating significant impact of attrition on small teams. 2. Related Work It has been argued that small teams deliver better results than large teams since they result in greater accountability/cohesion/commitment and reduced processes/paperwork [1]. Although, techniques to be followed in managing small projects/teams has received some focus in literature, but most of the published work addresses the issue of simplifying management processes [2-7]. All these published works suggest that although managers should not skip planning process and basic documentation requirements, but other management methodologies for large projects can be an overkill for small projects. Hence, managers should simplify project management methodologies/processes/frameworks. Team members in small teams are generally flexible to take up any tasks/roles/responsibilities since there is never enough manpower for available tasks [2]. We will suggest how managers should effectively utilise this fact to motivate team members. Manager of a small team is generally not sufficiently loaded. Hence, it has been recommended that he should also act as a Technical Team Member or should manage multiple small projects [5]. We extend that work extensively by proposing a range of possible multiple roles to be played by the manager in product development and services organisations. We suggest a scientific method of assessing “Personality Type” of the manager to decide his additional role.
    • 3 of 9 Methods for a manager to motivate small team members are presented in [6], suggesting the manager to lead by influence and not by authority. We will describe many more actions that a manager should take to motivate team members. 3. Desired Experience, Skills & Training Requirements for Managers The characteristics and requirements of managing small projects/teams are different from managing large projects. Hence, desired experience levels, management/technical skills and training requirements of managers are different. In large companies, the company has a pool of managers from which it can select the most suitable managers to manage small teams. We will discuss the desired experience/skills of managers to be assigned such roles. However, in small companies/startups, the total manpower in the company itself is small. Hence, all project teams are small, and all managers have to lead small teams. Hence, company does not have the luxury to assign managers with specific skills. For such scenarios, we will suggest training requirements to groom managers to meet the challenges of managing small teams. Managers of small teams face the following challenges – i) Managers generally look forward to managing large projects. Hence, it is challenging to motivate them to take up responsibility of small teams. ii) Since the project is small, senior engineers are not interested in joining such teams since the tasks are not challenging as per their experience. Hence, managers have to lead teams of young engineers. The managers need to groom these young inexperienced teams on project requirements/technologies. iii) In large projects/teams (product development/services projects), there are multiple senior personnel handling various responsibilities – Project Manager/Program Manager/Project Leads, etc. Since a small project is being managed by a manager with a young team, the manager is generally the sole senior person knowledgeable about the activity. Hence, the manager has to have expertise to act as the sole external interface for the product/project. iv) It is generally assumed that since the manager is not handling the challenges of leading large teams, he need not be highly expert in tackling interpersonal conflicts. Hence, interpersonal trainings for managers are generally ignored. However, on the contrary, this skill in managers of small teams is much more critical than for the managers of large teams. Assuming a team of only five engineers, even if two team members are having a conflict then 40% of the
    • 4 of 9 project gets impacted. The project is bound to be doomed. In comparison, a conflict among two team members in a large project has a very low impact. We suggest the following solutions to address these challenges – i) It is preferred to assign small projects/teams to rookie managers – i.e., managers who are recently promoted from Project Leads/Senior Engineers roles (say, 7-9 years experience). Since they are learning new management techniques, they would be excited and motivated on their role despite the team being small. ii) However, some small projects are complex and rookie managers cannot manage them. Further, in small organisations/startups all managers need to handle projects with small teams, including senior managers. Hence, a major challenge is to keep them motivated even when handling such responsibilities. We suggest such organisations to hire managers who are technically-inclined. Managing small teams allow them time to jump technically quite deep in the project/product, an opportunity not provided in large projects where they are loaded with a huge set of responsibilities/tasks. Hence, technically-inclined managers enjoy their tasks and remain motivated. If the managers are not technically strong then they should get trained/mentored in the technical domain of the project. A moderate level of technical skill is also acceptable since the manager can have an Architect in the team to handle complex technical tasks. iii) There are other reasons for the manager to have moderate to high technical skill. Being the sole senior person in the team, he is the sole interface to the external world for the product/project. Hence he must be able to technically understand the product/project, present it to external entities, understand their inputs and incorporate them in the product/project. iv) Further, small teams have low experience team members. A technically strong manager can quickly train/groom young engineers on the project requirements. Further, the impact of attrition within a small team is much higher than on large teams. A technically strong manager will have a deep understanding of the project requirements/design/technologies, and hence can ensure that the impact is minimised and new replacement joinees can be quickly brought up to speed on the project. v) As discussed earlier, unique management skills are required for managing small teams. Hence, we suggest the manager to at least undergo Covey’s “Seven Habits Training”. He should also get extensively trained on skills like – managing interpersonal conflicts; training/mentoring young team members; motivating team members; etc. 4. Multiple Roles for Managers
    • 5 of 9 Managers leading small teams have low workload. This low workload can sometimes demotivate the managers, especially if they are senior experienced managers. Low workload also results in managers having more time on hand, which leads to their micromanaging the team members and making them unhappy. Hence, we suggest utilising the additional time of these managers judiciously. As discussed in previous section, these managers generally have good knowledge of technical/business domains of the product/project. Hence, organisations should utilise their knowledge and assign them a dual role related to the product/project being managed by them. We suggest one among the following additional roles in product and services companies, respectively – i) Product Companies: - Product Management: The manager can play a product management role – study competing products, gather new requirements from customers and suggest new features to the product. - Customised Solutions: Customers sometimes look for an end-to-end managed solution instead of adopting only the core product. The core product needs to integrate with customers’ existing systems/software and needs to offer a range of additional features specific to their requirements. The manager can play the role of gathering inputs from key customers and suggesting customised solutions for them, which evolve into new services projects. - Architect/SME: Usually projects have dedicated Architects/Subject Matter Experts (SME). However, in the absence of such a technical expert, this role can be assigned to the manager of the project. This option should be exercised when the manager is technically very strong and can balance his technical tasks with management responsibilities. ii) Services Companies: - Business Development: The manager has good expertise in the technology/business domains of the services projects he is managing. He can play additional role of being a “Business Development Manager” in these domains. He can approach other customers having similar services projects requirements, present company’s expertise in the specified technology/business domains, convince the customers and win new services projects. - Architect/SME: for the services project.
    • 6 of 9 The decision on choice of the additional role for the manager depends both on his technical expertise and his psychological personality. We suggest that manager should undergo a scientific “Personality Type” assessment using Myers-Briggs Type Indicator (MBTI) assessment [8-10]. MBTI measures psychological preferences in how people perceive the world and make decisions. MBTI defines “Personality Types” as a combination of the following attitudes/psychological functions – Attitudes: Extraversion/Introversion Extraverts (E) are action-oriented, operating in external world of behaviour/action/people/things. Introverts (I) are thought-oriented, operating in internal world of ideas/reflection. Perceiving (information-gathering) Functions: Sensing/Intuition Sensing (S) individuals trust information that is present/tangible/concrete. For them, the meaning is in data. Intuitive (N) individuals trust information that is abstract/theoretical. For them, the meaning is in underlying theory/principles that are manifested in the data. Judging (decision-making) Functions: Thinking/Feeling These are decision-making functions based on data received from above information-gathering functions. Thinking (T) individuals decide from a detached standpoint, measuring the decision by what seems reasonable/logical/causal/consistent, and matching a given set of rules. Feeling (F) individuals decide by associating/empathizing with the situation, weighing the situation to achieve the greatest harmony/consensus/fit, considering the needs of the people involved. Judging versus Perception preference Judging (J) individuals show the world their preference for judging function. Perceiving (P) show their preferred perceiving function. Let us consider example of a technically “Moderate” manager with Personality Type “ESTJ”. Since he has only moderate technical skill, he cannot play the Architect role and should take up one of the other described roles. Since he is an “Extrovert” (E), he likes interacting with external world/people. Hence, he can be considered for a “Product Manager” role since he needs to interact with customers to understand
    • 7 of 9 their requirements. His Sensing (S) function allows him to gather tangible data about features/capabilities of competing products. His Thinking (T) preference, which is also his dominant Judging (J) function, allows him to logically evaluate customers’ inputs and competing products’ feature-set and decide right product features. 5. Motivating Team Members Since the team size is small, its members have limited challenges and growth opportunities. Hence, they could lack motivation. Hence, an important challenge for managers of small teams, as compared to managers of large teams, is to keep the team motivated despite these constraints. We suggest the following techniques to motivate the team – i) To start with, the manager should be careful in selecting the team members. In a small team, the manager handles most of the important functions with limited scope of delegating any major function to another senior team member. Hence, if the organisation has very senior engineers/project leads, who aspire to grow fast to management roles, then they should not be included in small teams. They fit better into large teams where they can get the responsibility of leading a subset of team for specific project modules. A small team should ideally consist of either young engineers or technically-inclined senior engineers, who aspire to grow in technical ladder (not management ladder). ii) The major benefits for members of small team are that they generally have complete view of the product/project and have direct interfaces with the Project Manager, Product Manager, internal/external customers, etc. In contrast, engineers in large teams have a narrow focus since they are exposed only to their specific project module, usually interact only with their immediate Project Lead, have limited interactions with the overall Project Manager and have minimal interfaces with external entities. The managers of small teams should utilise these facts to motivate their team members through following means – The Project Manager is responsible for interacting with external entities, like Product Manager and internal/external customers. In case of large projects, the manager generally includes the Project Leads of various modules in such meetings since they can share details of progress on feature-set of modules being managed by them. However, in small teams, the manager does not have the luxury of having Project Leads. The manager should utilise this fact to increase exposure of young team members. The knowledge of the complete project is distributed among all team members. Hence, the manager should include the concerned team members in meetings with these external
    • 8 of 9 entities when the feature-set/module being handled by them needs to be discussed. Hence, young team members get opportunities of interacting with Product Manager to understand how product/project strategies and feature-set are decided. They get opportunities to interact with customers to understand their requirements/issues and learn how to convert these inputs into features. This exposure gives them a broader perspective, trains them on tasks that usually engineers of their experience do not handle and prepares them for future major responsibilities. Hence, engineers are excited about their work. The manager should regularly interact with the team members and share with them the complete understanding of the product/project and show how it fits in overall company goals. This systemic view of the product/project and understanding of the criticality of their own role to the success of the overall activity, motivates team members to perform. The Architect in the team should be motivated by informing him that he is developing complete product/project architecture, instead of architecting a single module for a large project. Hence, he is handling major/complex/challenging task that prepares him for future responsibilities. In small teams there is never enough manpower for the available tasks. Hence, each team member should be assigned multiple tasks that will make him learn/apply multiple technologies/techniques, an opportunity that a small module in large project may not provide. Hence, the challenges being offered by the project keep him motivated. iii) Since team is small, the growth opportunities for team members are limited. Companies sometimes have very strict policies on percentage of team members who can be rated high, since they want to maintain a “Bell-Curve” in the organisation for performance ratings. E.g., the company may have a policy that only 15% team members can be rated at level “A”. In large teams, this aspect is not an issue since the possible number of members who can reach this high rating is limited and can fit within this limit. E.g., for a 30-member team, five members can be rated “A”, which is a reasonable number. However, if the team size itself is, say, only 6 then maximum one member can be rated “A”, which is very constraining for the manager, especially if he has more than one star-performer. Hence, the bell-curve has to be artificially applied to small teams, leading to employee demotivation. The solution is for the manager to convince the organisation not to force bell-curve on individual small teams but to spread it across multiple small teams. Say, create a pool of five small teams of 6-members each, to create a virtual team of 30 members. In Performance Rating Meetings, the managers of these teams can present their cases to “Engineering Head” to select the top 5 members among these teams for “A” rating. Since Engineering Head is aware of relative
    • 9 of 9 performance of each team, he can judge which teams have higher number of high-performers, and thus more members of those teams can be rated “A”. 6. Mitigating Attrition Impact The impact of attrition on small teams/projects is much higher than on large projects. E.g., even if a single member leaves a 4-member team, the project loses 25% of its manpower! The impact on his module and on overall project can be drastic. Hence, the manager must apply techniques to prevent attrition and mitigate its impact, if it occurs. The motivational techniques described in the last section can control attrition to a large extent. Manager can additionally apply the following techniques – i) As a first step, the manager should avoid choosing team members with the same last name! Say, if the team has a husband-wife combination then there is a very high possibility that both will leave together, in case one leaves the organisation to move outside the city. ii) Insist on team members holding regular knowledge sharing sessions within the team about their modules. Hence, if one member leaves then others are still knowledgeable about his work, which reduces the impact of attrition. iii) Manager should also formally groom backups for team members. In large teams, the managers have the luxury of having additional resources who are earmarked as backups. Unfortunately, small teams are always constrained of resources and hence cannot plan a backup within the team. The manager of small team should work in tandem with a manager of a large team in the organisation, to earmark an additional resource within that large team as a backup for his team. That engineer should be regularly involved in the project functions of the small team to be aware of the tasks being performed by other members. E.g., he can act as project design/code/test-cases reviewer. Hence, if a member of small team leaves then he is ready to join the team and takeover the leaving member’s module fast. iv) However, if the company itself is small/startup then the manager cannot fallback on another large team for creating backups. In such a case, the company should offload some project tasks to a services company. Hence, the services company’s resource can act as a backup for the small team. 7. References 1. Baker, B. (2009). In praise of small teams. PM Network, March. 2. Ladika, S. (2008). Bigger isn’t always Better. PM Network, March. pp. 36-39. 3. Kroll, K. (2007). Small Projects, Big Results. PM Network, July. pp. 30-33.
    • 10 of 9 4. Larson, R., & Larson, E. (2004). The Critical Steps to Managing Small Projects. PMI Global Congress – Prague. 5. Fuezery, G. (1998). Managing Small Projects. PM Network, July. 6. Rowe, S. (2007). Managing and Leading Small Projects. PMI Global Congress – Atlanta. 7. Rincon, I. (2006). Mini and Micro projects: Are the principles of project management appropriate for managing small companies or small projects? PMI Global Congress – Madrid. 8. Myers, I., & Myers P. (1995), Gifts differing: Understanding personality type. Davies-Black Publishing. 9. Jung, C. (1971). "Psychological Types". Collected Works of C.G. Jung, Volume 6. Princeton University Press. 10. Damle, P. (2010). Application of select tools of psychology for effective project management. PMI India Conference 2010, Mumbai, India. Author’s Profile Vimal Kumar Khanna is Founder and Managing Director of “mCalibre Technologies”, a software product company. He has over 28 years industry experience and has won multiple international honours. He is listed in “Marquis Who’s Who in the World”. He is also among 30 select experts in the world on “IEEE Communications” (pub. New York) Editorial Board (invited honorary position). His multiple independently- written papers have been published in leading international journals/conferences, including PMI North America, APAC & EMEA Global Congresses; multiple “PMI Asia Pacific e-Link” issues; PMI India Conferences 2010, 2011 & 2012. He has been interviewed in “PM Network” magazine.