Support.atimesheets.com



[pic]

|Date: |20th April 2007 |

|Issue: |1 |

|Revision history: | |

|Reference: |ImpRM.doc |

|Confidentiality: |General Distribution |

|Products covered: |Innate Resource Manager |

Introduction

The purpose of this document is to help you make best use of the Innate Resource Manager software. We identify the issues that need to be addressed during implementation and make specific recommendations; following these will make system implementation relatively straightforward. If you want to configure the system differently, we strongly recommend that you discuss your requirements with Innate before implementation and thoroughly check them out first in a test environment.

Implementing Innate software is not particularly complex, but for best results it should be treated as a project in its own right and be subject to the proper disciplines of project management. Having all those involved run through the product’s Guided Tour is an essential pre requisite.

Contents

This document consists of the following sections:

1. Pre implementation planning - identifying the key issues that need to be resolved.

2. Installing and configuring the software.

3. Data set up and administration

a. Data requirement tables list the default Innate data fields and enable you to add others you may require.

b. Recommendations on data set up for resources, working periods and calendars, projects and tasks, including use of Microsoft Project.

c. The sequence of data take on, which is important, and how to establish regular data feeds to and from other systems, if required.

4. Supporting your business process – how the system is best used to support the key steps in the resource management process.

5. Management Information – Using the range of reports to provide the information needed for improved visibility and control.

6. Hints and tips - a separate section is included and others are included in the text, using italics

7. Appendices provide further details on some aspects of implementation, such as permissions and integration with Innate timesheets, etc.

Organizational models

The majority of Innate installations operate in a matrix environment, where project and resource managers need to collaborate effectively to achieve the best use of scarce resources. In this document we focus on this type of organization, and assume that project managers need to negotiate with resource managers to get staff assigned to their projects. However, the system is also effective in team based environments, where the roles of project and resource managers are combined. Innate Consultants are experienced in a wide range of organizational models and the configuration options can support a range of organizational rules.

1 Pre implementation planning

The first step is a system implementation workshop, which is normally run by Innate. The workshop agenda document is included in Appendix 1 and identifies the issues that need to be addressed. In summary these consist of:

1. Understanding the business objectives for the system.

2. Documenting the required process steps.

3. Clarifying roles and responsibilities, so that data access permissions can be defined, etc.

4. Identifying data requirements and sources.

5. Defining reporting requirements.

6. Identify training requirements.

7. Planning the system implementation project.

There is a balance to be struck between adequately defining and policing the business process and relying on permissions to enforce it. Permissions are helpful for data security and for assisting your business process; however if they are too restrictive your users’ flexibility of operation is restricted. Our recommendations are set out in detail in Appendix 3.

2 Installing and configuring the software

Please refer to Innate’s technical documentation, which is accessible on the support web site at innate.co.uk. The principal documents are:

1. Data dictionary.

2. Configuration page.

3. Explanation of permissions.

An Innate Consultant will assist your IT support staff and DBA with installing the software, setting up the database, configuring the system and initial data take-on, Normally we customize the database using MS Access, before converting it to the operational database (SQL Server or Oracle).

It is important to do the initial set up in a non - operational environment, for thorough testing and evaluation, before implementing the configured system in the operational environment. We strongly recommend that this test environment is retained so that any subsequent changes to configuration, and software upgrades, can be checked out before being applied to the operational system.

Data back up and archiving policies should also be developed.

3 Data set up and administration

The reports you need and the way you want to use the system will determine any extra data to be stored. The Innate system is delivered with a sample database that can easily accommodate additional data elements on the projects, tasks assignments and resources data tables. Deciding on the additional fields is an important part of implementation planning, and reviewing the detailed report requirements is a good way of ensuring that all necessary data elements will be included.

Data setup has two steps. The first is to define the additional data fields that will be required; the second is to amend the data entry form scripts to accommodate these additional fields. These requirements are an output from the Implementation Workshop.

Many of the default data fields have particular functions within the software, e.g. the project owner field governs which projects are listed on each project manager’s home page. These rules are explained in the Data Requirement tables, shown in Appendix 1.

If you will be using Microsoft Project to plan individual projects, then any Microsoft Project field in the projects, tasks, resource and assignments tables can be mapped into Innate. The default Microsoft Project fields that are mapped into Innate are described in the Data Requirement tables, (Appendix 1).

The sequence of data set up is important, because later items depend on earlier settings. The following sequence must be adhered to:

1. Resource details

2. Work patterns and calendars.

3. Permissions and user groups

4. Project details.

5. Task details.

3.1 Resource details

There are a number of important considerations for setting up the resource data.

Primary search field

This is commonly the person’s generic skill, but could be their team or department. Defining work at the generic skill level is useful in a matrix organization, where project managers can only request staff, not allocate them. Generic skills are also useful to check the capacity to take on additional work. Innate strongly recommends their use for all but the smallest, team based implementations.

Innate applies the following conventions regarding generic skills:

• Define appropriate resource records for each generic skill with a calendar that has availability set to zero, (so there is no double counting of capacity). Set the resource name to be the same as the primary skill (stored in the Resource.Group field).

• We also recommend that generic skills are entered in CAPITALS for easy identification, in both the Resource.Name and Resource.Group fields.

Classifying generic skills

A simple list of skills can suffice, e.g., ANALYST, PROGRAMMER, etc., but many clients need a more precise classification. More precise searches and reporting can be achieved with a more detailed list of skills, e.g.

• DBA - Oracle

• DBA - SQLServer

• DBA - Progress

• PROGRAMMER - Java

• PROGRAMMER - .NET

• PROGRAMMER - VB

Other search criteria

The default database stores each individual’s primary and other skills to help identify alternative resource when those with the required primary skill are overloaded. There are 4 further search criteria that can be used to identify suitably skilled staff, such as other competencies, location, grade, skill level etc. These criteria can easily be configured during implementation.

3.2 Working periods and holidays

Working periods

We recommend that the standard working day be used as the working period, so work estimates should include an allowance for administration and other non productive time. The important point is to ensure consistency between working period, standard day and time recording practice, to ensure that planned vs. actuals comparisons, for example, will be meaningful. For ease of planning and reporting, we strongly recommend that the same number of hours per day apply to all working days even if, for example, Friday is a shorter working day. Otherwise, for example, a task which would occupy Wednesday and Thursday will not fit in Thursday and Friday but will finish some time on Monday. Of course, if you are planning to an accuracy of minutes and prepared to deal with the level of detail that involves, then you can set varying day lengths – the system stores day lengths and amounts of work to an accuracy of one minute.

Calendars and holidays

A number of resource calendars should be created.

• Create a calendar for each work pattern, e.g. one each for full time and each part time pattern, (Monday to Wednesday, etc), so that every resource can be assigned a relevant calendar.

• Use a meaningful name for the calendars e.g. Full Time 7 hours, Part Time 4 hours Monday – Thursday.

• Create a zero availability calendar for generic resources.

• Public Holidays should be included in all relevant calendars.

When creating a calendar use the Interval editor view to set the hours per day and then the Calendar view to set the non working days.

Personal holidays

We recommend that you create a ‘Holidays’ project to reflect all periods of non availability for each resource. This makes holidays very visible, much more so than if they are maintained in Calendars. Personal holidays are best administered centrally, by an administrator or team leaders.

The Manage Assignments view is particularly suitable for this.

Calendar for generic skills

Overloads shown in the Manage Assignments view will respect the resource calendars if ‘Use Resource Calendars’ is selected. We recommend that the Typical calendar for generics is set as the standard calendar to prevent new work being assigned to Bank Holidays etc. This will help you to find a real resource to do the work, without incurring an overload.

Allowance for Business as Usual work

Some roles, such as Infrastructure/Support will spend a significant part of their time on routine work and have only a small balance available for other work. We recommend that a Business as Usual project is set up to reflect the demand of non-project work, to ensure that each person’s availability for project work is taken into proper account.

If using Microsoft Project

The first check when setting up a new project in Microsoft Project is that the working time is set correctly – it must be identical to that defined in the Innate config.asp page. It is not possible to change the number of hours in a day retrospectively. It is also important to make the Microsoft Project calendar the same as the Resource Manager standard calendar, in terms of hours per day and hours per week and public holidays.

The default settings in Microsoft Project are 8 hours per day and 40 hours per week. If the settings in Innate are less, every Microsoft Project task will always be shown in overload.

3.3 Project details

Deciding on whether to use Microsoft Project or the Innate browser for a new project

New work can be defined in the most appropriate way, either using the Innate Manage Assignments table or Microsoft Project. Guidelines need to be implemented to ensure that new projects are planned the most appropriate way.

The Innate Manage Assignments table is suitable for the following types of work:

1. Simple projects, with a list of tasks where logical interdependencies between tasks are not required.

2. Operational type tasks, such as support, maintenance work etc,

3. High level estimates of major projects where they need to be scheduled around the existing commitments before they are scheduled in Microsoft Project.

More complex projects can be scheduled in Microsoft Project and kept in sync with the Innate database. You can register the new project in the Project details screen either before creating the Microsoft Project plan, or after synchronization, when the mapped fields will be populated into Innate.

Managers who use spreadsheets will probably find the Manage Assignments table simpler to use than Microsoft Project. It provides a spreadsheet style interface in the browser and data entry and edits are saved directly to the database. The Manage Work screens use data forms to access more information for selected assignment(s), while the Manage Assignments table is easier to use to deal with a set of assignments.

Project baseline policy.

Project baselines are snapshots of the project workload and can be taken at set points in the business process or on a regular rolling basis. Innate can store up to 5 project baselines, which are independent of those stored in Microsoft Project. A policy on taking project baselines needs to be implemented.

There are a number of fixed points in the business process where baselines should logically be taken, such as budget sign-off, agreed changes in scope, etc. When taking a baseline we recommend that you always put a comment as to the reason e.g. Budget sign-off given by A.N.Other on 1st April, or for rolling baselines, which month or quarter they relate to.

In addition, it is sometimes helpful to baseline the whole portfolio, e.g. for an IT Department baseline the total workload plan at annual budget time.

Baseline comparison reports are provided, so that the work impact of each baseline can be highlighted.

3.4 Task details

As explained in Section 3.3, project managers have the option to plan directly in Innate, (generally using project templates and the Manage Assignments spreadsheet view), or using Microsoft Project. A two step process can also be used.

1. High level resource estimates can first be entered in the Manage Assignments table to check the capacity to take on the project. Timelines show the bottlenecks and under utilization, so that realistic start and finish dates can be agreed.

2. For projects that warrant a Microsoft Project schedule, the data generated via the browser can be copied into a new Microsoft Project plan, typically at phase level. This gives the project manager details of the timeline and budgetary constraints, when preparing the detailed schedule. This process is detailed in Appendix 4.

Template projects.

Project templates are lists of standard tasks and assignments that represent how the organization wants to plan the work associated with different types of projects, e.g. development, infrastructure, etc. Templates are normally maintained centrally so that changes will be consistently applied by every project manager.

Whatever the size and complexity of the projects, it is recommended that templates are used when creating projects. They can be used for projects planned in either Innate or Microsoft Project. Use of templates helps with the standardization of task names, phases, etc. and can substantially improve the quality of reporting. Templates can range in detail from a simple list of standard tasks or phases, to detailed work estimates by skill, (for repetitive projects that warrant such detail). We recommend that as much detail as possible is included in template projects, as this is an important method of maintaining cross project data consistency.

When entering details of a new project in the Manage Projects screen, a pick list of templates is available. Entering the project start date for a new project sets the timescale for the template assignments, which can then be viewed and modified in the Manage Assignments table.

3.5 Data take on

Innate can provide tools to assist with the take on of existing data from Excel, Microsoft Project and other databases. The sequence in which data is taken on is most important:

1. Resource entries first.

2. Define work periods and holidays

3. Set user permissions

4. Finally, projects and tasks – the Business as Usual work first, followed by project plans in chronological or priority order.

Regular data feeds to and from Innate

Many clients use external systems as a source of resource and project data, and feed time data collected by Innate into finance systems, etc. Innate can provide data import/export mechanisms, or your DBA can facilitate direct database to database transfer. If direct database transfer is used, we can work with your DBA to design appropriate procedures and ensure that the integrity of the Innate database will not be jeopardised.

4 Using the software to support the key process steps

This section describes how we recommend the system be used, to support the common resource management process steps:

1. Registering new projects.

2. Demand management – project review and approval.

3. Allocating staff to tasks.

4. Tracking progress.

5. Changes in scope.

6. Closing projects.

7. Scenario Analysis – rebalancing the workload to overcome resource bottlenecks.

4.1 Registering new projects

Details of new projects can be centrally registered by the project office, by each project manager, or when the Microsoft Project plan is first synchronized. Central registration generally provides better support and control over the project review and approval process.

For systems that manage resources across more than one team, we recommend that all work is initially allocated to generic resource names. These can be by skill, team or group as previously discussed (see Section 3.1), but should reflect the most appropriate way of checking the organization’s capacity to take on new work. Whatever attribute is selected it should be stored in the Resource.Group field, (labelled Skill in the Innate default database, but this can easily be changed).

For major projects, you can directly enter a high level estimate for demand management purposes and subsequently create a Microsoft Project plan for detailed planning. Details of these steps are outlined in Appendix 4.

4.2 Project review and approval / Demand management

Skills capacity check

There are a number of interlinked reports that enable managers to drill down to the cause of bottlenecks, starting from the Pipeline Usage chart. These are particularly relevant for project review and approval meetings. The Pipeline Usage report can easily be modified to show the demand by any project field, but the most useful one is project status, so as to confirm that there is sufficient capacity for all committed projects,

[pic]

The sequence that we recommend is shown in the default home page for Ann Brown, a resource manager:

1. Pipeline histogram and table - click on a selected skill to show:

2. Resource usage for that skill - click on a selected person, or unallocated generic skill to show their

3. Task usage, which shows the source of potential overloads, at task level.

Should the impact of new projects, or a change in scope of an existing project, cause unacceptable bottlenecks you can use Innate’s scenario analysis to explore the effects of alternative courses of action. These do not affect the live data, until a scenario is accepted. We recommend that this aspect of the system is not implemented until the core process steps are bedded in. It is described in section 4.7

4.3 Allocating staff to tasks

It is good practice to check the skills capacity and re balance the workload, if necessary, before attempting to allocate work to individuals. This avoids pointless searching for individuals when none will be available. Within a matrix organization, each resource manager can view the demands for their generic skills using the My Unassigned Tasks report. When looking to satisfy these requests, Innate provides search facilities for the resource manager to identify suitably skilled staff and check their current commitments.

Replacing generic skills with appropriate staff.

All assignments that use generic skills as resource names are presented to the resource managers as requests for their staff whether they have been created directly in Innate or using Microsoft Project. Resource managers can choose between the Manage Assignments or Manage Work screens to replace these generic skills with real people, as explained in the Guided Tour.

Re - allocating work and editing work profiles

You can also use either the Manage Assignment table or Manage Work screens to replace previously assigned individuals with alternative resources.

If you want to edit the work content or profile of individual assignments it is much easier to use the Manage Assignments table.

4.4 Tracking progress

The most effective way of tracking progress is with Innate Timesheets, which fully integrate with Innate Resource Manager. As tasks are assigned to staff they will appear on that person’s timesheet as they fall due. Timesheets can be configured to capture both actual effort and estimates to complete their assignments and this can be used for:

1. Progress tracking, including updating Microsoft Project plans

2. Staff utilization analysis and reporting.

3. Project performance measurement reporting.

Appendix 5 sets out recommendations for using the two modules together.

4.5 Changes in scope

Changes in project scope can cause unforeseen resource bottlenecks, with the need to delay other work, or recruit additional resource. Copies of project plans before and after scope changes can be stored as Innate baselines and baseline comparison reports used to show the impact of the scope change.

Scenario analysis, described in section 4.7, is useful if the impact of scope change leads to unacceptable resource conflict; alternative scenarios can be developed to show any required delay to lower priority work, so that the scarce resource is freed up for the additional scope of work,

4.6 Closing projects

It is important to ensure that whenever a project is cancelled or completed it is closed properly within the system. This will remove work on any assignments going in to the future and free up allocated resources. A detailed explanation of the Close Projects facility, and implications on the standard reports is provided in the on line Help

4.7 Re balancing the workload with scenarios

The Manage Scenario option provides the full capabilities of Innate Resource Manager, but preserves the live data by working on a copy. This means that projects and work can be added, deleted or rescheduled to see the resource and commercial consequences of alternative scenarios, with no effect on the live data until acceptance.

When using the Gantt Move Projects, or Manage Assignments tables, we suggest that only those projects are selected that can feasibly be moved. Often this precludes projects that are close to completion or have sufficiently high priority not to be affected. Lower priority projects will be candidates for delay.

When negotiating with a specific client, just that client’s projects can be included. This is useful when they are exceeding agreed resource budgets. As projects and tasks are added, deleted or moved within a scenario, the Manage Scenario, Scenario Projects screen maintains a record of the projects that have been adjusted.

Please note that scenarios accommodate changes in the planned work load and do not model changes to resource availability levels; any changes made to the resource availability in a scenario will affect the live data.

For resource constrained organizations, such as IT departments, we recommend use of a priority field to identify low priority work suitable for delay, so as to free up scarce resource. Alternatively reports can be used to show the profile of additional resource skills needed (contractors?) to achieve all the work as planned.

Use of the project priority field and the pipeline management reports that show the resource loading by project status (Committed, Approved, Proposed, etc) are particularly useful when working in a scenario.

5 Management Reports

Innate provides a range of standard report layouts, each of which has a criteria screen that controls the data to be displayed. Each can be stored as an browser favourite, so that preferred criteria settings do not need to be remembered. The complete list of reports is described in the on line help but the table below describes how to use them to interrogate data for some common situations.

| | | |

| |Requirement |Report |

| | | |

| | | |

|1 |Demand management | |

| | Overall capacity to take on new work |Pipeline usage chart |

| | Spare capacity by skill |Resource Usage |

| | Which tasks contribute to a bottleneck |Task Usage |

| | | |

|2 |Resource management | |

| | Requests for my staff, list of tasks |My unassigned tasks |

| | How busy is my team, going forward |Pipeline usage chart |

| |Are my staff spending effort on planned work? |Planned vs. actual |

| | | |

|3 |Project performance | |

| | Which projects are over budget * |Over budget project |

| | Drill down to the details of each over budget project* |Project performance |

| | Compare planned with actual effort |Planned vs. Actuals |

| |* Requires Baseline Information | |

| | | |

|4 |Project baselines | |

| | How do baselines compare with each other and with current plans? |Baseline Task usage |

| | |Baseline Program Usage |

| | | |

| | | |

|5 |Scenario management | |

| | How do scenarios compare with each other and with the live data in resource |Scenario Resource Usage |

| |usage? | |

| | How do scenarios compare with each other and with the live data at detailed |Scenario Project Changes |

| |project and task level? | |

Innate will shortly release a reports wizard that will enable end users to modify the default criteria screens and report on any field in the Innate database.

For more complex reporting requirements, any Innate report can be exported to Excel for further manipulation, or the Innate report writing services used to develop a custom report.

5.1 Home pages

Each role can have a personalized home page that can be configured, using VB Script so that relevant report pages are displayed on entry to the system. The Standard home page indicate the type of information that can be displayed. The can be customized once the client has decided exactly what information is required.

6 Hints and tips

Throughout the text, relevant hints and tips have been included in italics. This section includes details of further suggestions, which are based on the successful use of the system by existing clients.

Replacing multiple assignments in a project with a single person.

There are 2 ways to do this

1. From within Microsoft Project, highlight all the required tasks before using Innate Resourcer button on the task bar

2. In the browser, Manage Work, Select Project, Select the required tasks, Replace. This option is better in a matrix organization where resource managers may not have Write access to Microsoft Project plans

On Manage Assignments how to see total workload on each person in the skill group?

Manage Assignments, select required resource group and all projects except templates. On assignments table, Toggle to table view if necessary. Sort on resource; collapse using ‘-‘ button

The best settings on Manage Assignments, Assignments Table, More

1. Always set Use Resource Calendars to Yes; this ensures that no work entered here is scheduled on weekends or Bank Holidays unless you specifically enter it on a daily view.

2. To check capacity, always set Usage in other projects, assignments to ‘Show at Top’.

3. If editing work without regard to capacity (for example when creating a new plan in the browser or editing a template), set Usage in other projects, assignments to ‘Don’t Show’. This is because you do not need that information at this stage.

4. Do not set to more columns or rows than you need. This is to keep best performance.

5. Also for best performance, do not select more resources than you need to view.

On Manage Assignments, Assignments Table, how to insert a task that exists in the database but is not visible on the current screen.

Right Click. New Assignment, Select Task, Add Resource.

On Manage Assignments, Assignments Table, Right Click, when should I use Insert?

1. To create a new assignment on the task use Insert Resource

2. To create an assignment on an entirely new project or task, use Insert Project or Insert Task.

.

On Manage Assignments, Assignments Table, Right Click, when should I use New?

This is the normal route from the Assignments Table to create entirely new Projects, Resources and Tasks (not MSP projects),

On Manage Assignments, never combine both real and template projects in the same selection.

Real projects represent real work that needs real resource capacity; templates do not.

How does a project manager request more work from an assigned resource on an existing task?

Create a new assignment on that task for the appropriate generic resource. If the existing resource assigned to that task is available, the resource manager can use Replace to assign them for the extra time, and the assignment is now a single extended assignment.

In creating an assignment for a generic, how can the project manager express a preference for a particular individual?

The system can be configured with a new assignment field ‘Preferred resource’ and Innate can add this to the appropriate data entry screens.

Appendices

1 Agenda for Implementation Workshop.

2 Data requirements tables – lists Innate standard user fields.

3 Roles and permissions - Using the Innate Permissions system to control data access.

4 Top down planning - How to prepare detailed plans in Microsoft Project using the high level estimates from Innate

5 Integration with Innate Timesheets.

Appendix 1 - Agenda for Implementation Workshop

The Implementation Workshop is likely to take between 3 – 5 hours. Facilities required will include a PC Projector and whiteboards/flip charts.

Purpose

The purpose of the workshop is to determine how the system will be used, its inputs and outputs and how the system will be configured. It may not be possible to make all of the decisions in the workshop and it may be agreed not to implement all features on day 1 – keep it simple is a good rule to follow.

Attendees

The implementation workshop should include representatives from all parties to the decision making process. It is strongly recommended that each attendee runs through the Guided Tours prior to the Workshop.

Agenda

1.1 Objectives of the new system

Why is the new system being installed, and what are the expected outputs? E.g. is it just to support staff allocation and reporting or will it feed into Innate timesheets?

1.2 Existing processes

For any Resource Management system to operate effectively it is essential that all concerned know and understand the process, and key roles and responsibilities of the people that will use the system. Process flow documents can be very useful. We support a range of processes, including

1. Matrix, where project managers specify resource requirements at the generic level and resource managers assign the individuals.

2. Team, where team leaders can specify work and assign staff directly.

1.3 Roles, responsibilities and permissions

From the process, the roles can be determined. Roles can be carried out by individuals or departments, such as the project office. Multiple roles can be carried out by an individual. The key roles typically are

1. Project managers.

2. Resource managers.

3. The project office.

4. Assigned staff (who may use Innate Timesheets).

5. Executives and project sponsor

6. System administration.

Understanding roles and responsibilities helps to determine the permissions required to control or limit what each role can do. Permissions relate to Projects and Resources. User Groups should be used when setting up permissions to make ongoing management easier.

1.5 Information sources

1. Resources - Will the resource information be imported from a Microsoft Project resource pool, imported from another source, e.g. HR system, or be entered directly into the Innate database using the administrator functions?

2. Projects & tasks - Will the task information be synchronized with Microsoft Project, imported from another source or be entered directly into the Innate database using the browser capabilities? We support a mix of Microsoft Project and browser based projects, so rules should be made on when to use Microsoft Project or Innate for project planning.

The data requirement tables in Appendix 1 list the Innate default fields. We recommend these lists are used to identify any other fields that will be required.

1.6 Information outputs

What information do the reports need to show? This will help define the fields required in the Innate Database. Examples of all existing reports should be gathered and any changes agreed at this stage, if possible. This is a good opportunity to simplify and rationalize reporting requirements.

1.7 Data Feeds

Is there a requirement for external data feeds, e.g. to a client billing system? Data import and export mechanisms exist, and can be modified to suit specific requirements.

1.8 System Configuration

1 Projects

Data is required to identify and classify projects for reporting purposes. Typically this information will include project number, client, project type, programme, status, sponsoring executive, etc. The standard data entry screen includes a number of common fields and can be modified using VB script, to meet client specific requirements.

Each added field can have its own data entry rules, e.g. from a pick list, set a default value, free text entry etc. Calendar wizards can be incorporated for date fields. Setting this up is part of Innate’s normal system implementation.

a. What information do you need to hold in the database and, if using Microsoft Project, what fields need mapping to Innate?

b. Review the default Manage Projects screen and project table layouts and define required modifications. Excel is useful for designing forms.

c. Define contents of all pick lists and any field default values that may be required.

2 Tasks

Projects are generally broken down into tasks and assignments. Tasks can be structured in a work breakdown structure, e.g. phases and tasks. Assignments represent the work planned for each individual who is ‘assigned’ to a task. Planning can be carried out at a high level e.g. project phases, or down to a detailed task level. There are a number of points to consider when deciding on the level of detail – size of project, reporting requirements, project control needs etc. A small project, lasting 2 – 3 weeks could be planned and controlled using 10 tasks, a major project lasting may months may need hundreds in a complex work breakdown structure. All sizes can be accommodated.

What task information do you need to hold in the database and, if using Microsoft Project, what database fields need mapping to what Microsoft Project task fields? Review the Manage Assignments view and define any required layout modifications.

3 Resources.

Data is required to identify and classify resources for reporting purposes. Typically this information will include staff number, line manager, cost centre, department, etc. The standard data entry screen includes a number of these options and can be modified to meet client specific requirements.

• What information, including additional search criteria, do you need to hold in the database and, if using Microsoft Project, what resource database fields need mapping to MSP fields?

• Review the default Manage Resources screen and resource table layouts and define required modifications.

• Define contents of all pick lists and any field default values where required.

4 Skills/Generic Resources

What skills will be required, or is primary resource allocation based on team rather than skill? List the Generic resource names to be used.

5 Assignments

What information do you need to hold in the database and, if using Microsoft Project, what Assignment database fields need mapping to what Microsoft Project fields.

6 Synchronizing

If using Microsoft Project rules need to be defined for synchronizing with the database - typically when a new project is ready for review, following weekly progress updates and when a scope change is required. The process documentation should state what triggers change in project’s status value. e.g. from proposed to approved.

7 Allocating Resources

Who will be allowed to assign resources? The rules need to be clearly defined in the process documentation.

8 Adding Projects/Tasks

Who will be allowed to add projects and tasks to the database?

9 Resource Pools

Are there any existing resource pools used with Microsoft Project? This data will need to be imported to Innate.

10 Calendars

The system allows for multiple Base Calendars and individual Resource Calendars. Standards need to be defined, as discussed in Section 3.2 of the Implementation Guide.

11 Permissions

The system controls who can do what by permissions – See Appendix 3

12 Reports settings

Hours per day, hours per week and days per month settings need to be defined and should be the same as those in the calendars’ working periods, for consistency.

1.9 Additional processes

Having decided on the way the system will work are there any additional processes that need to be put in place to support the system, such as assigning project names or numbers.

1.10 Additional documentation

Having decided on the way the system will work are there any additional documents that need to be created to support the system? They could be paper or Web based documents. As a minimum, we recommend:

1. Detailed process document

2. Customized product training course that incorporates your process steps and modified data screens.

3. Simple web based help for timesheet users.

1.11 Training

Identify who needs what training – project office, plan owners, resource owners, etc. Training can include one-to-one, PowerPoint presentation or one-to-many sessions. Training should include both system and company information i.e. why as well as how. A customized product training course that incorporates your process steps and modified data screens is recommended. It helps to reinforce the process and roles and responsibilities, particularly in a matrix organization.

Appendix 2 – Data Requirement tables

The full data dictionary in accessible on the support web site at innate.co.uk. The tables below list the Innate fields that are available for storing management information and exclude some Innate system fields. Space is provided for you to add details of additional fields that you require.

Resource data requirements

|Field name |Purpose |Rules |

|RE_Name |Resource or Generic Name |Must be unique |

|RE_ShortName |Used to identify Timesheet File Owner |Normally system generated but can be entered by client |

|RE_IsUser |Identifies users who will receive timesheets |Number of timesheet users restricted by Timesheets license |

|RE_Approver |Timesheet Approver |Typically team leader or manager |

|RE_ResId |System generated unique ID number |DO NOT EDIT |

|RE_Group |Primary Skill | |

|RE_EmailAddress |E-mail address used for sending alerts | |

|RE_SendTaskList | |Only used on E-mail Timesheet systems |

|RE_Exclude |Stops user names from appearing in drop-down lists |Only valid entries are X or Null |

|RE_LogonName |NT logon information – DOMAIN/username |Needed if using NT Authentication |

|RE_UseLogon |NT logon information |Needed if using NT Authentication |

|RE_RouterId |System field holding Resource Data |DO NOT EDIT |

|RE_SendTSByEmail | |Only used on E-mail Timesheet systems |

|RE_SendUpdateByEmail | |Only used on E-mail Timesheet systems |

|RE_Administrator | |Only used on Multi-administrator Timesheet system |

|RE_Rate |Hour rate |Can be used for simple cost reports |

|RE_OtherSkills |Secondary skills |Can contain multiple entries Comma delimited |

|RE_Search1 |Attribute field |Can contain multiple entries Comma delimited |

|RE_Search2 |Attribute field |Can contain multiple entries Comma delimited |

|RE_Search3 |Attribute field |Can contain multiple entries Comma delimited |

|RE_Search4 |Attribute field |Can contain multiple entries Comma delimited |

|RE_Resourcer |Resource Owner | |

|RE_BaseCalendar |System field holding Resource Data |DO NOT EDIT |

|RE_UserGroups |System field holding Resource Data |DO NOT EDIT |

|RE_RMData |System field holding Resource Data |DO NOT EDIT |

|RE_EmployeeId |Resource Employment number |Optional field |

|RE_HireDate |Resource start date |Optional field |

|RE_TerminateDate |Resource finish date |Optional field |

|RE_Status |Resource status e.g. full time, part time , contractor |Optional field |

|RE_Notes |Free format field for notes |Optional field |

|RE_CanActFor |Timesheet field identifying who can fill in timesheets for other users | |

|RE_CanActForAll |Timesheet field identifying who can fill in timesheets for all other | |

| |users | |

|RE_Template |Timesheets V5 field identifying timesheet design | |

|RE_TemplateA |Timesheets V5 field identifying timesheet design for approvers | |

Project data requirements

|Field Name |Purpose |Rules |

| | | |

|PR_Name |Name of the project |Need not be unique but it is recommended. PR_projid field stores unique id. |

|PR_Approver |Name of approver for all time booked against a project | |

|PR_Progresser |Name of person who can apply timesheet data to the Microsoft Project plan | |

|PR_Exclude |Excludes completed projects from timesheets, so no more time can be booked |Only valid entries are A, X or Null |

|PR_ProjectType |For classifying projects by type |Normally uses client defined pull down list |

|PR_Client |For classifying projects by client |Normally uses client defined pull down list |

|PR_Administrator | |Only used on Multi-administrator Timesheet system |

|PR_Resourcer |Project owner |Controls list of projects grouped under “My Projects” |

|PR_ProjectManager |Project Manager |Controls list of projects shown in each project manager’s home page |

|PR_Start |Current Planned Project Start Date |Field mapped when using MSP |

|PR_Finish |Current Planned Project End Date |Field mapped when using MSP |

|PR_Cost |Current Planned Project Cost |Field mapped when using MSP |

|PR_Work |Current Planned Project Work Effort |Field mapped when using MSP |

|PR_BaselineStart |Original Planned Project Start Date |Field mapped when using MSP |

|PR_BaselineFinish |Original Planned Project End Date |Field mapped when using MSP |

|PR_BaselineCost |Original Planned Project Cost |Field mapped when using MSP |

|PR_BaselineWork |Original Planned Project Work Effort |Field mapped when using MSP |

|PR_RemainingHours | | |

|PR_OLAPExclude | Stops information about the project appearing in reports | Yes/No field |

|PR_Status | |Used for classifying projects in pipeline usage report |

|PR_IsTemplate |Classifies a project as a template project. |Template projects are excluded from all work based reports & are for making new plans |

|PR_ActualStart |Actual Project Start Date |Field mapped when using MSP |

|PR_ActualFinish |Actual Project End Date |Field mapped when using MSP |

|PR_ActualCost |Actual Project Cost |Field mapped when using MSP |

|PR_ActualWork |Actual Project Work Effort |Field mapped when using MSP |

|PR_Description |Description of project | |

|PR_RequestedBy | Who has requested the work |Need not be somebody on the system |

|PR_RequestDate |Date project initially requested | |

|PR_Program | For identifying what Programme a project is part off | |

|PR_Priority |Project Priority | Default setting for field is number |

|PR_Billable |Checkbox denotes if work planned / done on this project is to be billed to the | |

| |client | |

|PR_Notes |Free format field for notes | |

|PR_ProjectDocument | url link to project document or folder | |

|PR_PercentComplete | | |

| | | |

|Other commonly used | | |

|fields | | |

| | | |

| | | |

| | | |

| | | |

| | | |

Task data requirements

|Field Name |Purpose |Rules |

|TA_Name |Task Name |Field mapped when using MSP |

|TA_Approver |Timesheet Approver for task |Rarely used |

|TA_ProjId |System Field |DO NOT EDIT |

|TA_TaskId |System Field |DO NOT EDIT |

|TA_AllUsers |Timesheet field – task to appear on all resources timesheets | |

|TA_Exclude |Timesheet field used to stop time being booked to tasks |Only valid entries are X or Null |

|TA_Unique Id |MSP Unique ID |DO NOT EDIT |

|TA_Start |Task Start Date |Field mapped when using MSP |

|TA_Finish |Task Finish Date |Field mapped when using MSP |

|TA_Text1 | |Field mapped when using MSP |

|TA_Outline Level |MSP field information |DO NOT EDIT |

|TA_NotInPlan |System Field – used to identify deleted tasks |DO NOT EDIT |

|TA_ParentTasks |System Field – used to identify parent tasks in MSP |DO NOT EDIT |

|TA_SummaryTasks |System Field – used to identify summary tasks in mSP |DO NOT EDIT |

|TA_Milestone |System Field – used to identify milestones in MSP |DO NOT EDIT |

|TA_ParentId |System Field |DO NOT EDIT |

|TA_RMData |System Field |DO NOT EDIT |

|TA_Priority |Task Priority | |

|TA_Notes |Free format notes field | |

|TA_PercentComplete |% complete information |Field mapped when using MSP |

|TA_BaselineWork |Baseline work |Field mapped when using MSP |

|TA_BasleineStart |Baseline Start Date |Field mapped when using MSP |

|TA_BaselineFinish |Baseline Finish Date |Field mapped when using MSP |

|TA_BaselineStart1 |System Field |DO NOT EDIT |

|TA_BaselineStart2 |System Field |DO NOT EDIT |

|TA_BaselineStart3 |System Field |DO NOT EDIT |

|TA_BaselineStart4 |System Field |DO NOT EDIT |

|TA_BaselineStart5 |System Field |DO NOT EDIT |

|TA_BaselineFinish1 |System Field |DO NOT EDIT |

|TA_BaselineFinish2 |System Field |DO NOT EDIT |

|TA_BaselineFinish3 |System Field |DO NOT EDIT |

|TA_BaselineFinish4 |System Field |DO NOT EDIT |

|TA_BaselineFinish5 |System Field |DO NOT EDIT |

Appendix 3 – Using the Innate permissions system to control data access

Permissions are used to restrict what individual can do. This may impact on the ability for them to carry out their role. In the first instance it may be better to have the system as open as possible and only apply permissions if there are problems.

The roles can be determined from the process. Typical roles are Project Managers or Plan Owners, Resource Managers, Approvers and Progresser (if using timesheets and Microsoft Project). Roles can be carried out by individuals or departments, e.g. Project Office. Multiple roles can be carried out by an individual.

The key roles typically are

• Project managers.

• Resource managers.

• Assigned staff (interface with timesheets).

• Executives.

• System administration.

Understating roles and responsibilities helps to determine the permissions required. Permissions control or limit what an individual can do. Permissions relate to Projects and Resources. User Groups (see below) should be used when setting up permissions to make ongoing management easier.

Permissions in Resource Manager describe what actions each user is allowed to perform on each object. Users can be specified individually or by groups such as "Everyone". Actions include such things as Delete, Read and Write. Permissions are attached to the objects rather than the users.

Resource manager supports permissions on the following objects:

• Projects

• Resources

• Calendars

• The Projects collection

• The Resources collection

• The Calendars collection

Permissions on a single object (i.e. projects, resources and calendars) affect what users are allowed to do to the object itself. Permissions on collections come in two parts: (a) what users can do to the collection itself and (b) the permissions that new objects created in the collection will inherit.

1 Specifying Permissions

To change the permissions on an object you need to be the object's owner or the owner must have granted you permission to change the permissions.

1.1 Single Objects

You specify permissions for the objects in your database via the browser. For project and resource permissions, select the object in the normal way using Manage Projects or Manage Resources respectively. Then select a suitable data entry form, typically "Project Permissions" or "Resource Permissions". Note that it is possible for a script writer to configure other data entry forms to provide the ability to set and view permissions.

For calendar permissions, select the object in Base Calendars. Then use the Options page to enable the display of permissions.

Note: it is not possible to specify the permissions on an object until it has been created, i.e. until after your press Save. For example, if you select the Project Permissions data entry form and click New you will not be able to set any permissions until you click Save. However you can set the default permissions to be given to all new objects.

1.2 Collections

Permissions on collections come in two parts:

• Permissions on the collection itself. For example, you need Write permission on the Projects collection in order to create a new project in the database.

• Permissions that will be inherited by new objects that are created in the collection.

For example, suppose the projects collection permissions list contains an entry "Fred: Read + Write, Full Control". The first part means that Fred has Read and Write permission on the projects collection itself (but has no effect on Fred's ability to access individual projects). The second part means that Fred will get Full Control permission on any new projects that are created.

To specify permissions on a collection use the Security menu.

2 Permissions Lists

You specify permissions for an object by adding, deleting and modifying the permissions list associated with it. Each element in the list consists of a user name or user group together with a set of actions. Collection objects have two sets of actions for each element, one for the collection itself and one for new elements created in that collection.

Permissions are cumulative. That is, to find the effective permissions for a given user you add together the actions allowed for that user individually and the actions allowed for any groups that the user is a member of. The exception to this rule is that "No Access" (i.e. an empty set of actions) overrides all other permissions.

The owner (or "Resourcer") of an object always retains Read and Change Permissions permission, even if the permissions list specifies otherwise.

3 User Groups

Innate Resource Manager allows users to be put into arbitrary groups and then permissions assigned to the group as a whole. It also supports a number of predefined groups to make specifying permissions easier. These groups appear in the pick lists of users on the permissions pages in the browser. The predefined groups are:

• Everyone. All users automatically belong to this group. For example, suppose project X has a permissions list entry "Everyone: Read". The effect is that all users are allowed to read project X.

• Creator. This applies only to collection objects. It specifies the permissions that the creator of new objects will get. For example, suppose the projects collection permissions list contains an entry "Creator: Read + Write". If Fred creates a new project he will have Read and Write permission on it.

• Self. This applies only to the resources collection. It specifies the permissions that new resources will get on their own resource records. For example, suppose the resources collection permissions list contains an entry "Self: Read". If Fred creates a new resource called "Sally" then Sally will get Read permission on her resource record.

Innate recommends that permissions are always specified for user groups rather than individuals. This makes management much easier when staff leave or join the organization.

4 What Permissions Do I Need?

The table below describes what permissions you need in order to perform certain operations. Project, resource and calendar descriptions have been combined where appropriate because they are quite similar.

|Operation |Required object permissions |Required collection |

| | |permissions |

|See my name in the login pick list |- |- |

|Create project/resource/calendar |- |Write |

|See a project/resource/calendar in the Manage |Read or Delete |Read |

|Projects/Resources or Base Calendars pick list | | |

|View project/resource/calendar details |Read |Read |

|Update and save project/resource/calendar details |Read + Write |Read |

|Change the Resourcer field in a project/resource or Owner in a |Read + Change Ownership |Read |

|calendar | | |

|Change the permissions (except Baseline permission) on a |Read + Change Permissions |Read |

|project/resource/calendar | | |

|Change Baseline permission on a project |Read + Change Permissions |Read + Baseline |

|Delete a project/resource/calendar |Delete |Read |

|Close a project |Write on the project. You do not need any |Read |

| |permission on the resources assigned to the | |

| |project. | |

|Baseline a project or delete a baseline |Read + Baseline |Read |

|View the permissions on the projects/resources/calendars |- |- |

|collection | | |

|Change the permissions on the projects/resources/calendars |- |Change Permissions |

|collection | | |

|Select a project in Manage Work to view tasks and assignments |Read on the project |Read (Projects |

| | |collection) |

|Add, delete or modify tasks in Manage Work |Read + Write on the project. |Read (Projects |

| | |collection) |

|Add, delete or modify assignments in Manage Work |Read + Write on the project. Assign on the |Read (Projects |

| |resource. |collection) |

|View project, resource, task and assignment data in reports |Typically Read on the project and/or resource |- |

| |but this depends on the report script. | |

|Synchronize a project in the Add-in |Write on the project. Assign on the resources.|- |

|Add, delete or replace assignments in Innate Resourcer in the |Write on the project. Assign on the resources.|- |

|Add-in | | |

Appendix 4 – Top down planning

How to prepare detailed plans in Microsoft Project using the high level estimates from Innate

Note – cannot be used with MSP Project Templates

This appendix explains how Innate can support the following process.

1. Register a new project centrally, using an Innate template that has high level estimates.

2. Modify the default estimate, using the Manage Assignment screen.

3. Check that sufficient skills capacity is available, and approve the project.

4. Create a new Microsoft Project plan that shows the approved estimates.

5. Paste in template modules for each phase, and adjust the detailed estimates to satisfy the limitations copied from Innate.

The Guided Tour explains steps 1, 2 & 3.

The screenshot below shows the high level estimate viewed from the Manage Assignments screen.

[pic]

4 Create a new Microsoft Project plan that shows the approved estimates.

1. Open Microsoft Project, click the Innate Resource Manager button on the toolbar and Create Plan.

[pic]

2. Highlight the new project, Enhancement F, and click Create. This creates a new plan in Microsoft Project and populates it with the approved estimate from Innate.

[pic]

3. Insert new blank rows between the existing rows, to accommodate the detailed Microsoft Project templates.

5 Paste in template modules for each phase, and adjust the detailed estimates to satisfy the limitations copied from Innate.

1. For each of the phases in the new project, open the detailed template plans in Microsoft Project. An example for the design phase is shown below

[pic]

2. Highlight and copy these tasks and paste them immediately below the design estimate row in the new project. Adjust the start date of the Design task 1 to match the start date for the Design estimate.

[pic]

3. By displaying the Work column, the project manager can now adjust the detailed tasks for the design phase, to ensure that the overall dates and work content remain within the estimate copied from Innate. Because the approved estimate can be stored in Innate as a project baseline, the summary rows can be deleted once the detailed plan has been prepared. Reports in Innate will highlight any phases that exceed the approved estimate.

[pic]

Appendix 5 - Integration with Innate Timesheets.

1. Remaining work goes to zero in MSP for any period where actuals have been entered either directly or using Project Progresser. So when the plan is resynchronized with the Innate Resource Manager database, there is no plan for these dates. Hence if you wish to compare actuals v plan, you need to take a baseline in Innate first. Then use the report ‘Baseline Planned versus Actuals’

2. There is a field Assignments Remaining Hours in Innate Timesheets. This field is not automatically timephased by Resource Manager. If you are using MSP and Progresser, then Remaining Hours will go back to MSP as Remaining Work, and MSP will time-phase it . So when you next synchronize your MSP plan with Resource Manager the time-phased work will show.

3. Unallocated Assignments – show in Res Mgr only if you want to add further work using the Manage Assignments screen?

4. Define appropriate resource records for each generic skill with a calendar that has availability set to zero, (so there is no double counting of capacity). Set the resource name to be the same as the primary skill (stored in the Resource.Group field). This convention ensures that generic names are excluded in the list of timesheet users.

5. An existing Timesheets system (Version 4 or Version 5) can be upgraded to support Resource Manager.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download