i) Abstract

An Assessment of the Factors Influencing the Building of

   Effective Software Teams    

  

Stewart Ross 0900319

(Management of Software Projects)

Edinburgh Napier University

2801 Words

This paper will attempt to address the main factors and issues involved when a team has been assembled for a software development project. I will aim to provide the key points backed up by real world examples and give solutions to common problems that can arise, as the topic of teamwork has been greatly studied for many years. I will condense the key findings and relate them to 21^st century software team examples.

With the correct methodology and leadership skills by the project manager, most tasks will be completed successfully and efficiently, however finding the “happy balance” of optimal productivity and work output whilst maintaining a good subordinate work attitude with time for ideas and free thinking is a skill found through experience.

The goal of every project is to produce an end result that has taken full advantage of every member’s individual and combined skills, and completed to a pre-anticipated schedule, and with the correct approach, is very accomplishable. 

1) Introduction

This research will aim to discuss the factors of what effective and preferred team qualities are ideal for a software development project. The items discussed will cover the following topics –

Time management / Scalability

Project Planning

Effective Managerial skills by a project manager

Problem solving

Other topics covered will be effective usage of team resources, specialisation and optimisation of time at hand.

For a project to be efficiently run on time, and be of specification, communication is paramount both from the client and project team perspective, as well as having good relationships between team members and managers.

Before any work is undertaken, there must be extensive planning to ensure that all members are on the same “wavelength” and understand fully, basic protocols for what to do if extenuating factors or changes in specification hinder a projects timeline.

In this article I will list possible risks and problems that could happen in any project and the standard ways of resolving them based on references found in workplace reports and books about project management.

In the coming chapters I will list quotes and techniques from previous studies in the field of project management. As it is not specific to IT alone, there is vast inquisition of this information and many papers and articles already written, I will compare results and opinions. The range of time that the references adhere to vary from as recent as 2012, to as early as 1900, however much has changed in this timescale based on many years of successful and failed examples.

An example of some of the range of books found include –

“Teamwork and Project Management (3^rd Edition) – Karl A. Smith 2005”

“JK Pinto 1986 Project Implementation: A determination of its critical success factors, moderators and their relative importance across stages in the project lifestyle”

As you can see by the dates, project management is not a new field of study; the changes however between the issues listed in 1986 and 2005 will be significant, such as the expanding use of technology in all projects, not just software development. However there is one consistency and that is the fields regarding human interaction strategies which remain the same.

2) Planning

“By failing to prepare, prepare to fail” (Benjamin Franklin)

This should be the first stage of initialising a project, and should involve a meeting with all colleagues in the team, as well as an establishment of roles that will be given to each member. Set goals and timescales (which will be further discussed later in this article) as well as performance requirements should also be set and all arrangements fully understood by each person. (Smith 2005)

“When developing systems, always engage the subject matter experts within the business departments in which the systems will be implemented and use them as a basis for establishing sound business requirements” (Holmes 2001).

The client should be reassured by the level of planning to ensure that the final product is up to required specification and not manipulated by poor understanding in the project planning stages.

“Apply your craft with professionalism, professionalism means amongst other things, taking the time to understand the business in which you work, not just the technology” (Holmes 2001)

The colleagues and the manager should also have their professional and personal life adequately balanced so as not to cause frictions (Viera 2005) more on this falls under the scalability section.

By planning the specific timescales and framework of the project, this allows each member of the team to be clear about what is expected of them  specifically and what is someone else’s field.(Holms 2001)  Doing this boosts overall productivity later in the implementation stages. (Viera 2001).

In the planning stage, a common approach is to totally segment each part of the project down into manageable chunks that can then be allocated to each individual or a few members of the team. This can then allow specialists to focus on their field of professionalism and get the most out of everyone’s talents, whilst also making strategic monitoring of the project more visible. A modular programming approach is also highly recommended, with backups regularly taken, as well as security protocols such as passwords.

If the project is designed to be done in stages, for instance the documentation after the implementation, certain stages can be done simultaneously (i.e. if the task was to create an application of which the general user interface is already produced, but the rest of the background functionality is still being developed, The team members allocated to the documentation phase can begin to create a user manual based on what is present via communication with the development team) (Viera 2001)

Timescales are important but what is more crucial is the overall team health and ability to overcome problems, If the team is able to maintain a strict schedule however the schedule was unknowingly affecting the quality of the work output, then that shows a poor communication between colleagues and managers, as it is the managers job to ensure that workload has been made realistic and not overburdening or demoralising (Bull 2010).

3) Scalability

“The definition of scalability is the ability of a system, network, or process (in this case a project), to handle a growing amount of work in a capable manner, or its ability to be enlarged to accommodate that growth. Also known as the timing and process scheduling of a project”. (Wikipedia 2012)

This comes under planning however as the vast majority of the planning stage ends after the initiations and group meetings, it should be made certain that the scalability remains maintained, adhered to and altered if necessary throughout the length of the project until the end result.

The scalability should be measured by taking “risk analysis” of all possible outcomes, and have procedures and protocols in place that everyone in the group is aware of. Again this also falls under problem solving section later in this report.

Some of the reasons that projects fall behind schedule, include,

over supervising and under supervising staff and doing jobs that can be automated in this day and age with a computer. (Viera 2005) Although a good manager should be able to balance this well, and create a fair and optimised timetable of work. Managers should also liaise with the client in creating all timescales as this will determine how many hours are needed to be paid for in a financial since. (I.e. an estimate of final costs) The client will also have deadlines to meet of their own, so this is highly important to set right.

An example of a time management and scalability plan could be to make some form of graphs, possibly a Gantt chart, this creates an overall understanding of when all deadlines are, and will greatly increase the team “gelling” to motivate one another through the tasks. However if the schedules are created for each individual it means they can also be more self sufficient (i.e. if a team member is absent or if the manager is not present, work and managerial tasks have already been set so it is not a disaster.)Teamwork is essential but individual self reliance the key to modular success. (Pinto 1986)

Overall estimation of the project requires a process of organising and acquiring data, this may in a very large project be done by independent engineers or subcontractors, in some cases a “Professional Estimator” may be hired. He/She is not involved in the project itself but instead simply looks at all factors related to costs and time. (Field 2007) 

4) Managerial Skills

A good project manager is both devoted to the task at hand and to the wellbeing of the team members. They should be responsible for –

Preparing the project plan – this should involve communication with all team members, and the client. Furthermore they should be competent in coordinating and managing the ongoing work after the planning stages and into the implementation phase.

The work should be monitored, perhaps involving weekly meetings and progress reports. Risk analysis should be undertaken in the planning stages and throughout the length of the team to analyse any potential failings, or alterations required in the schedule that may effect the final delivery date. (Nieborak 2012)

Discussions and meetings with the client should also produce an estimated budget; this will take into account factors such as hours per day, number of members in the team, size of the project, and how urgent it is.

Domestic issues such as conflict and misunderstandings if they occur should be mediated through arranged discussions with both sides of the argument; however this is covered in higher detail in the problem solving section.

All legal agreements and contracts both for the client side and for the workforce should also be processed through the project manager. This also makes the project manager liable for any legal issues that may occur, and this should be taken into consideration. (Nieborak 2012)

There are times when the project manager may have to make difficult choices and decisions, ones that will possibly make themselves “unpopular” but be of the most benefit to the overall wellbeing of the project. A good leader must not make decisions based on personal interest, advantage or for one set individual reason, Making a bad decision will be a costly mistake and can affect confidence both between team members and in the project manager. (Field 2007) 

5) Problem Solving

 “Software problems are not natural disasters like earthquakes or tornadoes, in which human actions are more or less inconsequential. In fact software disasters are entirely man made and we have the ability to prevent them from occurring if we choose to do so.”(Holmes 2001)

For any project to be successful problems should be pre anticipated (as mentioned in the scalability section) Although no matter how much planning and how much risk analysis has been done, it is still inevitable that something may go wrong. This could include factors related to human nature, such as de-motivation, personality clashes, or ill health of an essential team member. It is the job once again of the project manager to come up with a solution to whatever issue may arise.

“Project Management success is 80% art (the people skills) and 20% science or technology based” (Flannes 2001)

It is important for the manager to have the correct people skills to arrange a mediation or workaround. However this can only go so far, if for instance a member of the group is acting inappropriately or in a non professional manner, disciplinary procedures must be taken into action and this could vary from a verbal warning, temporary suspension or even complete dismissal. Preferably disciplinary action should be of a “learn from your mistakes” approach, constructive and unbiased of personal opinions and not in the nature of discrimination or persecution. This of course depends on many factors, such as frequency and severity of the individual’s behaviour. (Avins 1972)

What should be considered if poor productivity or behavioural issues arise is if they are being over / under supervised or over worked, which can be a fault in the planning stages. All members of the team should have regular breaks, as it has been shown that regular breaks actually increases morale and productivity, also team building. (Goessi 2010) It can also promote a positive attitude, and a friendlier working environment. It is preferable to be friendly with your colleagues, and ways of “icebreaking” between new teams are common in the workplace. This includes things such as away days, teambuilding exercises and meetings. Although having a social foundation is highly advantageous, there needs to be a clear line drawn on socialising and working, or this can lead to lessened outputs of productive work, for instance if the staff spend more time discussing off topic issues than discussing how to tackle their allocated module of the project.

Other types of problems that may occur may be things such as being under or over budget, being behind the time scale allocated or sudden changes in the client’s requirements. What makes a good team is adaptability; this includes an agreement to flexible working hours and a dynamic approach to the project as a whole. If the team successfully looks ahead as one and manages each others resources well together, most obstacles can be overcome if announced from the manager.

It is the management’s responsibility to make changes to issues involving salary, budgeting and client to project communication. The most vital aspect of this is feedback from every member of the team; it is important that no problems are “covered up” or even remain unaware until the last minute.

6) Conclusion

To reiterate all points in this report, a summary of the important factors of a software development team include –

The ability to manage time effectively with a clear risk analysis of all the problems that can arise within the project, the key to this is to combine every member’s ideas and make sure that the team feels comfortable working together so that they voice their opinions.

The ability to make the best use of resources and of each member’s specialities, for instance it would not be optimal to have a programming specialist in an accounting style role.

Upon research, it is defiantly evident that extensive planning has the highest benefits in any given team exercise. This allows each member to individually know what specific role he / she may be in, and what is expected from them. The process of planning will also create a sense of community and allow the team to bond together.

Setting out clear hierarchies and role descriptions to the team is also key.

A good relationship between all staff in contact with the client (for example managers, estimators etc…) will create a good working relationship, and aid in formulating budgets and timescales.

The “headstone” of any project is of course the leader, and the role they play is crucial to the team wellbeing and the projects final results. The project leader / manager must be fair but firm, and sometimes be “cruel to be kind”. It takes a certain type of personality and set of people skills to be an effective project manager (Vieira 2005), and if the role is carried out well, they should be seen as approachable and self confident.

All potential problems should be pre anticipated if possible, although should any unexpected and perhaps unwelcome issues arise, there should be protocols in place to keep the project to schedule and to budget.

To finalise the most crucial elements of a successful software development team are communication, planning, effective management and the ability to overcome problems. You only reap what you sow regarding software projects; therefore the final result will be an indication of how well these elements were adhered to.