The way a project team is structured can play a major role in how it functions. Different styles of team will have different characteristics. For example, do we wish to encourage discussion with the business representatives or to keep them at arm's length so the developers can make good progress? Careful consideration of team composition and reporting relationships can make a big difference to the results.
The various roles in the team will depend on the nature of the project. As well as the main team roles, consider the other participants and how they fit into the picture.
Project roles and resources will have been identified as
part of the planning,
estimating
and resourcing
process. Note that the resources and optimum way of
working will normally change during the project. Often an initial
high-powered team will define the business solution, followed by
a much broader team to deliver it, and then a line management and
operational team to operate it. The will be a core team who
remain fully involved throughout the project, but others will
need to be brought in as required.
Team structure will probably be adjusted at each stage to meet the evolving nature of the project. The right structure for a small, high-powered, business-design team is unlikely to work for a large applications development team.
There are two main structural dimensions to the project team:
For example, a website designer might be working with business managers and network specialists to create a storefront whilst another website designer is working with different business managers but maybe the same network specialist on an Intranet application for presenting internal management information on sales - both as part of the same project. So, does it make sense to have a team of developers, a team of managers and a team of network specialists, or should we have a team for the storefront and a team for the management information system?
Here are some basic rules that may help you decide how to structure the teams:
People working together in a team usually see their teammates as "being on their side". They will normally work together and help each other to achieve their collective goals.
Placing people in the same team generates collaboration, knowledge sharing and skills transfer - for example, between the specialists in a software package and the key future users of that package.
Building a good, effective team is vital - team structure will influence the way the team behaves. Aim to create a collaborative team, where individuals share knowledge, co-operate, support each other and are motivated to achieve the team's goals.
Interaction between team members is the best way to get a balanced view of all perspectives, eg business needs, practicality, technical feasibility, efficiency, performance.
The understanding, knowledge, and capabilities of people working in other teams are rarely exploited to the full.
People working in other teams are often viewed as a nuisance - they interfere with our team's progress.
According to the complexity theory, putting a large number of people into a single team creates more interplay than progress.
We will take a look at some example team structures below. First, let's consider the roles within those teams.
There are many different roles in addressing a full business solution. Some of these will probably form the core full-time project team. Others may be part-time specialists, and others might be representatives of various groups interested in the project. As well as identifying the type of person, it is often necessary to give thought to the level of capability or power. If we need someone who can take a business decision we must identify the right person. If we need someone to do routine work, we should not waste the time of a more expensive resource.
Core team roles will normally depend on what you are doing. For example, you might need sales managers, website designers and Java programmers, or you might need accountants, systems analysts and COBOL programmers. Other roles may depend less on the specific solution; for example, you almost always need a Project Manager.
Here are some common project roles along with a brief explanation:
Role | Explanation |
Project Sponsor | The person who saw a need for change and had the authority to make something happen. There may be several sponsors who collectively have this role. It may be that even higher authority and support is required such that others should also be drawn into this role. |
Supporting Sponsors | To succeed in all aspects of the project in all parts of the organisation it may be necessary to establish many supporting sponsors at different levels and in different organisational units. |
Project Director | The person with genuine executive authority over the project. The Project Director has full accountability and responsibility for the project's success, and has the power to make all decisions, subject to oversight by the executive bodies. |
Executive Committee | A body of people representing the overall executive authority of the organisation. This might, indeed, be the Board of Directors, or it could be a delegated sub-committee of the Board |
Steering Committee or Project Board | The group of people charged with regular oversight of the project. Collectively they should represent all significant areas of participation in the project and they should have authority to take decisions on behalf of those areas. Members would typically be departmental heads, Vice Presidents, or Directors, along with external representatives. The Project Director and Project Manager would normally report to the Steering Committee. |
Project Manager | The person with day-to-day responsibility for the conduct and success of the project. The Project Manager would normally have control over all project resources. |
Project Office Manager / Staff | The "Project Office" provides supporting shared services to the Project Manager and to the overall Project Team. Often this function has a manager plus support staff. Typical responsibilities include controlling and tracking the detailed plan, managing documentation, preparing reports, etc. It may also be the place to house part-time specialists supporting the team, for example, a Training Designer. |
Project Accountant | A large project may require its own accountant to deal with procurement, sub-contractor expenditure, joint venture accounting, progress tracking and financial reporting etc. |
Team Leader | Typically the project will be divided into various sub-teams - each with its own Team Leader. Team Leaders would be responsible for the management and coaching of that sub-team. They may also have responsibility for managing and tracking the detailed sub-plan for their team. |
Organisational Change Manager / Facilitator | A specialists in identifying issues, requirements and solutions regarding organisational change, ie corporate or individual rational, political and emotional factors in bringing about the desired business change. |
Communications Specialist | A specialist in communicating messages within the organisation. There will normally be a range of communications media that the project should exploit in achieving its goals. |
Business Process Reengineering Specialist | A specialist in the process and techniques of re-engineering business processes to gain optimum performance. |
Process Owner | The person within the organisation with overall control, authority, and accountability for any given business process. |
Process Specialist | An expert in best practice solutions for a given business process. |
Process Manager | A manager within the organisation with detailed understanding and experience of how a given process operates. |
Process Modeller | A specialist in modelling business processes such that potential improvements can be defined and quantified. |
Solution Architect | A specialist in defining overall business solutions with responsibility for the "big picture". |
Technical Architect | A specialist in defining technical components of a business solution with responsibility for the technical architecture of the solution. |
Organisational Design Specialist | A specialist in the assessment of resourcing needs and capability levels, plus the design and achievement of the revised resourcing and organisational structure. |
Solution Designer | A specialist in the detailed design of solution components. There will, in fact, be many different types of specialist in this category as each needs to be a specialist in the aspect of the solution they design, eg database designer, website designer, program designer, package configuration designer, network designer, procedure designer etc |
Developer / Programmer | A specialist in the creation of solution components. Again, there will be different types of developer depending upon what is being developed. |
Network and Telecommunications Specialist | A specialist in the design and construction of networking and telecommunications. They would deal with internal and external networking issues, such as architecture, hardware, capacity/bandwidth, etc |
Marketing Specialist | A specialist in marketing. Where the solution has an external element, it is important to consider how to make it attractive to the external people and bodies concerned. In particular with eSolutions, such considerations will form a fundamental part of the design of the solution rather than just an exercise following the completion of the solution. |
Training Specialist | A specialist in identifying training needs then designing training approaches and content to meet those needs. |
Training Developer | A specialists in the development of training materials. Often the most efficient approaches to training delivery will require some or all of the content to be created and delivered electronically. |
Trainer | A person with the skills and knowledge required to deliver training content. |
Documenter / Technical Writer | A specialists in the creation of accurate usable documentation - both for the day-to-day use of the solution and as design documentation for future reference. Documentation in modern solutions will normally be supported electronically, eg using workflow software and context-sensitive help information. |
End User | End users form valuable resources in the team - they can be used for many purposes related to the design, construction and delivery of the business solution. As former members of the team they will return to their departments as experts and coaches for the new solution. |
Computer Operations Analyst / Staff | A specialist in the way the live technical solution should be operated. Operating procedures would include routine operations, controls, security, backup/recovery, disaster plans, etc. |
Facilities Manager / Staff | The people responsible for the provision of appropriate accommodation for the revised organisation to perform the new processes. This may be simply some adjustment of existing facilities or it might amount to the acquisition and construction of entire new facilities. |
Lawyer / Legal Adviser | A legal specialist who would deal with various contractual matters such as detailed contracts for the provision of equipment or services. |
External Auditor | The external accountants who are responsible for the audit of the organisation. They may need to review the plans, designs and completed solution to ensure it meets an adequate standard from an audit perspective. |
Internal Auditor | An employee of the organisation charged with responsibility within the organisation for maintaining standards and procedures. |
External Regulator | Many industries and are subject to various forms of regulation by external regulators. There may be a need to co-operate with these regulators or to maintain specific records or information to meet their requirements. |
Quality Manager | A person responsible for processes and procedures that ensure required levels of quality are achieved. |
Quality Auditor | A person responsible for the Quality Audit - ie checklist adherence to declared procedures and deliverables. |
Case Study |
A local health authority
finance manager who was about to implement new accounting
systems was attending a briefing about implementation
projects. We explained all the different roles that might
be needed to deliver a complete solution. He said " but I can only spare a half day a week and there's just one technician who handles all our IT." We did not have an acceptable answer for him. |
There are many ways to organise the team. Take a look at these examples. Think about why these teams might have been structured in these ways. Then take a look at the commentary about them.
In this structure the
major functional areas have been addressed by teams
focused on that area. The team would have a mix of people
so that all the necessary skills, knowledge and
understanding are collectively within that team, subject
to any further specialised support that is needed. The technical elements of the overall solution have been recognised as requiring a team of specialists, so, in fact, we have part of the team structure fully process-structured and another part in a resource pool form. Other features in this example:
|
This is a very similar
structure to the previous one. The main teams have been
defined to support the major business processes within
the scope of the project. Specialised shared service
teams have been set up - one for all the technical
support areas and one for non-technical general and
specialised support, eg change management and training. Other features in this example:
|
This structure is based
on the traditional resource pool concept. Teams are
constructed from similar types of resource. People often
feel more comfortable in teams like this, but they do not
necessarily combine together so effectively to produce
solutions. For any given issue, a combination from
different teams will need to communicate and collaborate.
For example, design by prototyping would be conducted by
members of the user team and the applications team. In some IT environments, the staff believe separation from the business and users is an advantage. They find the "interference" from users slows their progress. This may well be true - but close collaboration with the business will normally improve the quality of the solution and prevent the risk of delivering a solution that is not valued by the user community. Usually teams are constructed to promote collaboration, knowledge sharing and skills transfer. One particular, and unusual, use for this structure is where you wish to minimise skills transfer. This has been considered valuable in a few cases where there is a significant shortage of a particular skill in the marketplace. Why? Because if you transfer skills to the line staff they all resign to double their salary as consultants - see the case study below. Other features in this example:
|
Case Study |
A large multi-divisional body were implementing multiple SAP systems at a time when there was a great shortage of SAP experience available in the marketplace. By the end of the programme, every member of staff assigned to the project had resigned to take up a better-paid job. |
![]() |
Copyright © Simon Wallace, 1999-2016 |