Enq: Thomas Mathiba

15
Enq: Thomas Mathiba TERMS OF REFERENCE DEVELOPING AND IMPLEMENTING AN IT –BASED PROJECT MANAGEMENT SYSTEM

Transcript of Enq: Thomas Mathiba

Page 1: Enq: Thomas Mathiba

Enq: Thomas Mathiba

TERMS OF REFERENCE

DEVELOPING AND IMPLEMENTING AN IT –BASED PROJECT MANAGEMENT SYSTEM

Page 2: Enq: Thomas Mathiba

1. PROJECT TITLE

Developing and Implementing an IT-Based Project Management System

2. BACKGROUND

Skills development is one of the major challenges facing the new South Africa on its way to improved living standards for the majority of the population, increased productivity levels and a higher competitiveness on the world market. The Skills Development Act promulgated in 1998 lays the foundation to redress the past by introducing new training systems which place special emphasis on enabling the formerly disadvantaged to actively participate in the country’s economic activities.

Since the launch of the Skills Development Strategy in February 2001, a lot of Sector Education and Training Authorities (SETAs) have made significant contribution in taking forward the broad objectives of the Skills Development Act. Some SETAs have succeeded to effectively co-ordinate education and training programmes at the workplaces by using practical project management approach to manage the learnership implementation. Whilst project management was once the exclusive job of project managers who most often coordinated the activities of specialized, complex, large scale projects, in the more recent years, however, the role of project managers and project management has been changing. The applicability of the project management has widened to include projects of a broad range, from a simple to a complex, and from manufacturing to service and education and a host of other areas. Based on the success of the project management approach within the SETA environment, it is gradually emerging that because projects bring together people from a range of jobs, they are diverse and flexible, and provide them with the opportunity to collaborate in a unique way, SETAs are increasingly finding project management approach as a preferred way to fulfill the needs of their stakeholders and achieve the National Skills Development Strategy targets.

However, at issue with most SETAs is the lack of an IT-based project management system. What is required is a system which outlines the project management body of knowledge, tools, techniques, processes, procedures, templates and standards to be applied to meet project requirements.

The purpose of the project management system is to ensure that management of multi functional projects is performed in a logical flow of activities to guarantee good results, achieve overall project goals and eliminate shortcuts. Unless projects are scoped, planned in a similar way their quality is compromised resulting in lack of focus and inability to achieve organizational goals.

2

Page 3: Enq: Thomas Mathiba

Wholesale and Retail SETA context

In 2003, the W&RSETA commissioned a research to review the operations of the Projects Office and how that could be improved. Amongst others, the research report noted that the system at best was lacking in sound processes, tools, and overall project management system. One of the key shortcomings with regard to methodologies and processes within the project office was that documented processes are not fully applied by the project managers and there are inconsistency in project documentation and filling. The ambiguity of projects reports made it virtually impossible to workout real performance based on what was reported. Review of the files was not sufficient to surmise the current state of affairs on any of the projects. Lack of project plans made it difficult to measure performance against plan.

The research report went on to make some recommendations which briefly indicates that:

A Project Management System be developed and implemented and should detail project management methodologies and processes that are strictly applied.

All documentation formats, layouts and level of detail required need to be standardized and must involve all key stakeholders.

The system should ensure that projects are managed within the three pillars of proper project management: Budgets, Schedule and Quality.

The standard should be more or less the same for all projects. All should include but not limited to the purpose, level of detail, for whom they are written and expected outcomes

Equally important is that projects undertaken should be defined in terms of their characteristics and type. All projects initiated should focus on how the respective project will contribute towards the attainment of all DoL targets for the organization.

There should be proper documentation and filling To this extend the W&RSETA would want to request proposals from providers to develop and implement a Project Management System.

3

Page 4: Enq: Thomas Mathiba

3. OVERALL PROJECT OBJECTIVE

The overall objective of the project is to develop and implement a Project Management System to support the W&RSETA business processes in an automated way.

4. SCOPE OF THE PROJECT

4.1 Project Management: Provide full project management for this project

The provider will have to provide the following: project management engage in a scoping and planning exercise define the business objectives of the project develop a strategy for meeting them.

The activities should include developing business and technology strategy, define the change imperative, building a business case, assess the change readiness, determine processes and system risk assessment, develop project team technical environment, and define overall training strategy. 4. 2 Designing the system

4.2.1 Defining the system

This will require the provider to formulate a clear statement which reflects a precise understanding of the scope and nature of a problem. Establishing a definition serves two purpose: it will commit the organization to developing an appropriate information system which will serve the needs of the organization and its stakeholders, and serves as a benchmark against which the system can be measured once it is operational. Defining a system requires the input and agreement by the Wholesale and Retail SETA line functionaries. 4.2.2. Identifying reporting requirements

The provider should identify reporting requirements as the next procedure in building an information system. Unless it is done, it is impossible to know what data will eventually have to be collected. Particular attention must first be paid to recognizing all user groups. Developing proposals for reporting formats speeds up the process because stakeholders have something to respond to.

4.2.3 Specifying operational requirements

4

Page 5: Enq: Thomas Mathiba

The provider will have to interview the end-users to note the operational requirements, and definitely before determining software and hardware requirements, and definitely before the system building procedure begins. The best source of operational requirements information is the Projects Office and the line function managers who will use the system. The system must meet the following operational requirements;

Form part of the W&RSETA policies and procedures, Be customized to SETAs type of projects Be user-friendly Be available to everyone dealing with projects Even though each project scope will differ, the planning, implementation,

monitoring and reporting should be the same both at documentation and detail level.

It must lend itself to expansion as line functions and stakeholders identify new information needs.

It should ensure greater inter-operability and integration of different applications

Facilitate continuous improvement in the technology

4.2.4 Technical standards

The provider will be expected to define the under-mentioned technical standards that would begin the process of rationalizing technology and explain how they will work to enable the Project Management System to share data and inter-operate with other systems.

Networking protocols Operating systems Data-bases and data-warehouse Middle-ware Transaction processing Desktop environment Multi-media standards

4.2.5 Identifying data elements

It is required that the provider transform the reporting requirements into data requirements or elements. This means deciding which pieces of raw data must be collected and processed in order to produce the reports requested by information users. The provider must identify data elements meticulously. Attention also need to be given to how the data is to be entered. As this procedure gets under way, related data elements should be grouped together in order to create data files.

5

Page 6: Enq: Thomas Mathiba

4.2.6 Determining the equipment requirements

The provider will have to define the tools, supplies, machinery or materials which will be required to operate the system. Equipment could mean a certain software application running under specific computer operating system environment. It is however important to keep in mind that not all systems require essentially the latest technology to operate effectively.

4.2.7 Building the system

The procedure to be followed consists of three sub-procedures:

4.2.7.1 System design: the provider should lay a physical design of the system. It is required the relationships and dependencies are established between the groups of data elements, or data files, in order to determine how data files interact with each other. The result of this sub-procedure should be a schematic diagram which will be used to guide the system builder.

4.2.7.2 System development: The builder should use the design document to start the process of establishing what the data entry forms will look like, what data will be entered onto which paper forms; how the data will be entered; how output, in the form of reports will be generated.

4.2.7.3 Software set up: Install and configure the system to provide the required support to line functions. The provider will configure and pre-test the system to confirm that it supports the target vision, and define the required custom development work. Activities include designing the To-Be processes and technology requirements, configuring the processes in the software, creating the training curriculum, and developing technical specifications for conversion, reports and forms.

4.2.7.4 System testing: The builder should ensure that the system functions correctly. If errors are found the builder of the system must locate the source of the problem, repair it, and test it again. The builder should from time to time consult with Projects Office and line function managers to find out about the user’s impressions of the look and feel of the system.

4.2.7.5 Writing system documentation: the provider should document the procedure which have been followed as the system development proceeds.

Technical documents: The technical documents should describe in detail every aspect of the development process, from the point of defining the system through a detailed description of what went into the building of the system. No elements should be ignored –a detailed record of the work which has been done to date

6

Page 7: Enq: Thomas Mathiba

must be put down in writing. This will enable a new system builder to build on what a previous one has done.

User documents: A user document or manual is crucial. Many users may be at a complete loss when using a newly built system unless they can refer to a well-written user manual. 4.2.7.6. Implementation and Training: The project team should validate and implement the integration of the new business processes, the software, production technology, processes and systems security and controls, and organizational infrastructure and workforce changes. Activities should include performing integration and end-user training, performing process and technology cutover activities for “go live’. 4.2.7.7 Project Review: The provider should outline a project review process

4.2.7.6. On-going Support and Maintenance: The provider should outline how on going support and maintenance will be offered.

5. DESIGN AND IMPLEMENTATION PHILOSOPHY

Needs Analysis

The provider should outline how he/she will conduct a joint needs analysis of specific requirements with the Projects relevant line functionaries. The core system to be tailor made to suit the needs of the Wholesale and Retail SETA business process.

Concentrate on core requirements

Based on the results from the needs analysis, the provider should sequence the requirements and concentrate on core requirements

Effective implementation is critical

The Wholesale and Retail SETA regards effective implementation of a working business system rather than the installation of a software as critical. Hence, it is important to the Wholesale and Retail SETA that a clear plan of action to deal with on site support, personnel training is provided.

6. EXPECTED OUTCOME AND DELIVERABLE

A fully functional Project Management System Customised Financial Management System A trained Projects Office staff A trained W&RSETA management and staff

7

Page 8: Enq: Thomas Mathiba

A customized projects office (front and back) in electronic format (CD) Technical documents User documents

7. COMPETENCY AND EXPERTISE REQUIREMENTS

The provider should: Be registered as an accredited training provider Have track record Have the capacity to develop and implement the system Be able to design training manuals Have the necessary capacity to facilitate training

8. SERVICES DESCRIPTION

Project Management Software set up Customisation and Installation Implementation and Training Project Review On-going Support and Maintenance

9. APPLICATIONS / FUNCTIONALITIES

9.1. Projects Financial Management System

The system should be able to perform the following:

Project Earned Value Graph

Should be able to measure a series of categories and overall performance within a project.

Measure project performance Planned Value, Actual Value, Actual Costs Monetary value to time and cost Forecast estimate to complete the project based on current

performance

Financial Reports

Project Budgets Work performed versus work scheduled Budget cost versus actual cost Quality of the project Project expenditure and balance

8

Page 9: Enq: Thomas Mathiba

Project spending status on quarterly and annual basis

9.2 Project Reports

The system should produce structured reports specifically for the four phases of a project life cycle. Reports should be based on the following:

Planning Implementation Monitoring Evaluation

9.3 Project Flow Charts

The systems should produce flow charts

Project Feasibility Report process Project Charter approval process Project Approval process Budget approval process Change Request process Procurement / Consultant process etc.

9.4 Projects Templates

The system should be able to produce the following templates:

Project Information Index Action Log Communication tracking Log Correspondence Log Project Contact Details Quality Review Checklist Organisation Chart Resource Specification Form Budget Approval Form Risk Management Form Risk Management Log Risk Assessment Risk Action Log Resource Assignment Matrix Task List Milestone Table Minutes and Actions from meetings Change Request Form Change Request Log

9

Page 10: Enq: Thomas Mathiba

Fault Management Form Issue Management Form Issue management Log Log of Plans and Deliverables Documentation distribution Work breakdown structure Project status reports Monthly reports

9.5 Project Management Procedures

The system should produce procedures to be followed with respect to:

Project definition Risk Management Exception Management Quality management Human Resource management Cost management Communication Change management Procurement management etc.

9.6 Project tracking

The system should be able to track project performance in relation to project milestones, deliverables, targets, budgets and timeframes etc.

9.7 Project Standards

The system should produce standards that refers to the processes, applicable objectives and deliverables concerned with:

Project Initiation Scope planning and definition Work-breakdown structure Organization Estimating Project Plans Exception Management Risk Management Procurement Management Quality Management Communications Management Change Management Project Plan Execution

10

Page 11: Enq: Thomas Mathiba

Cost control Schedule control Reporting Close-out

9.8 Project Documentation and Filling

The system should be able to manage, file, store and retrieve all project related documentation in a standardized format which includes and not limited to the following:

Project register Document tracking file Project Charter Project Plan Project Budget Status Reports Payments Receipts Change Request Contracts with consultants Status reports from consultants Minutes of meetings Strategy information Technical manuals Statutory documents Vendor information etc.

10. REPORTING REQUIREMENTS

The service provider will:

Report directly to the Project Manager Submit monthly progress reports Submit an evaluation report at the end of the project Make presentations on request to W&R SETA Projects Board

11. TIMEFRAME

This project is for the duration of 3 months

12. EVALUATION CRITERIA

CV of providers Costing Methodology and Approach

11

Page 12: Enq: Thomas Mathiba

Historically Disadvantaged Individual Proven Track Record

12