Project Launch Process L130

Blog: Biz-Performance, David Brown

L130 – Detail / Revise Staffing, Team Structure and Organisation

DEFINITION

Based on the segment plan, the detailed project staffing and organisation may be reviewed and agreed. The required resources must be acquired.

SUMMARY

The objectives of this process are:

to identify and assign resources to the Segment Plan, and
to review the plan and organisation structure of the project to ensure that they meet the requirements.

It is an iterative process that would normally be conducted in parallel to finalising the Segment Plan.

Steps are:

identify / negotiate resources available,
assign resources to specific tasks,
enter details into the planning tool for scheduling,
optimise the schedule.

At any point, if the required resources are not available, then these should be acquired.

As a result of the total planning process, it may be necessary to revise the project organisation structure.

PATH PLANNING GUIDANCE

This process is optional. It is appropriate when the project organisation is not of a trivial nature and has not already been finalised.

DEPENDENCIES

Prerequisites (Finish-Finish):

Detail the segment plan (L120)

Dependent procedures (Finish-Finish):

Mobilise resources (L160)
Set up/review user involvement (L170)
Set up/review management organisation (L180)
Present project/segment approach to user community/team (L200)

RECEIVABLES

Project Constitution showing terms of reference, scope and objectives (L010)
Quality Plan (L080)
Path Plan (L090)
Project Organigramme, job descriptions and charters (L100)
Organisation structure of the client organisation
Available resources details / skill sets
Segment Plan (L120)

DELIVERABLES

updated Project Organigramme, job descriptions and charters
updated Segment Plan showing resource allocations

TOOLS

ITPM Core Guide
Example plans
Project planning software
Example organisation structure for project / sample job descriptions.

DETAILED DESCRIPTION OF TASKS

Resource assignment

The list of resources available to work on the project should be determined and assigned to the detailed work plan for the segment (“Segment Plan”). Software package implementation support/help desks may be able to help with any specialist expertise that is required.

If appropriate, it may be necessary to negotiate with line managers within the client organisation and external organisations to obtain the right quality, quantity and mix of resources. The project sponsor and other key managers within the client organisation would normally be involved in these negotiations and should certainly agree to any staffing arrangements which affect the expected costs or benefits.

Thought should also be given to the use of personnel from the package vendors to perform work in the linkage between the application and the technical infrastructure, for example using Software Company staff to set up the Application Software development, test, and production system or tuning the performance of the overall system.

The resource assignments should take account of the following:

assigning appropriate resources to each task in terms of experience, skill and availability (ie not necessarily the most experienced),
minimise the number of resources assigned to each task,
shared resources should be minimised across plans,
average resource availability to the project (taking into account the amount of time spent on support & overhead tasks),
individual resource calendars eg allow for holidays & training courses.

The information should be loaded into a planning tool to schedule the entire plan. Manual schedules are not appropriate due to the amount of time involved. Other task considerations can also be checked at this point, for example estimates and task dependencies.

When the plan is scheduled, it can then be optimised to ensure:

resources are not overloaded,
resource utilisation is close to availability,
resources are logically assigned,
resources are only working on two or three tasks at a time.

If a good planning system is used and sufficient attention has been paid to defining the individual tasks and dependencies, it should be possible for the process to be automated. Typically, the staffing mix and assignments used will lead to some inefficiencies in the scheduling of tasks, for example, everyone might be waiting for a user to finish a training course simply because that user has arbitrarily been scheduled to define the needs for a specific process. It is usually possible to optimise the plan further by adjusting these assignments and, possibly, seeking a different mix of resources at given times in the project. However, at all times the project manager should be seeking to be realistic in the assumptions – if staff resources are planned to perfection, the imperfect reality of real life is bound to make the schedule unachievable.

Organisation and structure

As a result of the planning process, it may become apparent that the organisation of the project may require updating, for example, too many resources reporting to one project leader, or additional teams needed for specific areas of the project. The project manager should review the organisation carefully to check for this.

There are many considerations concerning effective project structures. The best teams usually have a combination of skills, so that collectively the team can address all aspects of a given area of the overall project. In a Application Software Implementation project this will usually lead to teams addressing specific areas of business processes, functionality, applications, modules and system components. Each team is likely to require a combination of people who:

understand the business,
understand package-focused implementation,
understand the concepts and design for the new system,
understand the technicalities of the new system and the environment within which it will operate.

Depending upon the functional area concerned, this usually leads to a mixed team which might include:

team leader,
end-user managers and staff,
consultants specialising in package-focused business solutions,
business analysts
package module specialists with industry knowledge,
package base system specialists,
IT systems analysts or business analysts,
vendor system technical specialists.

In addition to the functionally oriented teams (which may contain technically minded people), there will often be a need for purely technical teams. The technical teams might address such things as developing custom programmed interfaces or conversion suites, managing the technical infrastructure, developing reports, creating additional online transactions, custom. Technical teams may include:

team leader,
systems analysts,
developers specialising in the package’s programming language, eg ABAP
legacy system programmers,
technical specialists in various aspects of the technical environment (eg Unix) and architecture (eg database, communications, operations, security), and
technical specialists from the vendor organisation.

SIIPS Example of a project structure.PNG

Other formats of project organisation may be appropriate. The following two charts show example project organisations for the Project Model and Design/Prototype/Construct phases of an SAP project.

Project organisation for Project Model

Project organisation for Design, Prototyping and Construction