Project Management

PROJECT MANAGEMENT RESPONSIBILITY CHART The responsibility chart shows for each milestone what organizational unit or project group is involved in achieving the respective milestone. There are eight distinguished roles a group, departement or function can assume: •

D: takes Decicions solely or ultimately

•

d: take decisions jointly or partly

•

P: manages Process and controls progress

•

X: eXecutes the work 

•

C: must be Consulted

•

I: must be Informed

•

T: provides Tuition on the job

•

A: is avaible to Advice

Linear Responsibility Chart

A project achieves specific objective within constraints of time, cost and quality. In project, there are several participants which are as follows: General Manager: Executive chief of the organization Manager of Projects: Chief of project department Functional Managers: Chiefs of functional departments Project Manager: Chief of a specific project

The authority and responsibility of the various project participants in the activities and decisions of the project can be: a) Actual responsibility for getting the job done.  b) General supervision responsibility. c) Must be consulted. d) May be consulted. e) Must be notified. f) Must approve. There should the clear authority-responsibility relationships among the project participants so as to remove confusion and conflicts in project. The main mechanism for such purpose is Matrix Responsibility Chart (MRC). Linear Responsibility Chart is also known as linear chart (LC), Matrix Responsibility Chart (MRC), Responsibility Interface Matrix (RIM), Responsibility and Accountability (RAM). It is the chart of responsibility which identifies the project participants and shows authority and responsibility relationship among the project participants due to their overlapping involvements in project management. The participants may be general manager, manager of   projects, project manager and functional managers. It clearly specify the authority and responsibility relationships of project participants to avoid confusion and conflicts. Specially, it is used in matrix organization structure in order to minimize the confusion and conflicts  between project manager and functional managers. It explains what and who of project work. It links the project activities or task to the responsible person which ensures effective implementation of project to achieve defined objectives within constraints. LRC is prepared to find out responsibility center of all key activities in the project and for  those purpose, LRC is divided into rows and columns and numbers. The rows of LRC indicate activities, responsibility and authorities. The columns identify the position of the project  participants and numbers indicate the degree of authority and responsibility existed between rows and columns of LRC, the numbers can be symbol. The Matrix Responsibility chart is divided into: a) Rows: They indicate activities, responsibilities, authority.  b) Columns: They identify position of project participants. c) Numbers: They indicate the degree of authority-responsibility existing between the rows and columns. They can be symbols.

Linear Responsibility Chart Symbols/ Codes: 1 = Actual responsibility 2 = General responsibility/ General Supervision 3 = Most be consulted 4 = May be consulted 5 = Must be notifies 6 = Must approve

The advantages of Matrix Responsibility Chart or Linear Responsibility Chart are as follows: It describes the role of project participants in project matters. Authority, responsibility and accountability for project activities are delineated among various project participants. Problem-solving becomes easier. Communication is facilitated. It cuts red tape.

It is a useful tool for supervising of authority and responsibilities. There is delegation of authority. It postures coordination because it clarifies rules and responsibility, authority and responsibility relationships for project activities among the participates. It reduces confusion and conflict between project manager and functional managers. It helps to monitor  responsibility of project participants. It combines organizational structure with work   breakdown structure which makes easy to fix responsibility to project participants. The disadvantages of Matrix Responsibility Chart or Linear Responsibility Chart are as follows: It does not describe about people interactions in the project. It is a mechanical aid. All relationships may be difficult to delineate. Customer-imposed requirements may limit its usefulness. It acts as mechanical tools for fixing responsibility only but not defines the relationship  between project participants. It tries to express authority-responsibility relationship in specific terms. But situation and degree of all relationship may be difficult to express. Project is customer oriented and always impose requirement. The requirement may limit the usefulness of LRC. Project management is an important task for businesses of every size. In small business,  projects are often driven by a problem that needs a solution, for example, a company specialising in home energy assessments may wish to make regular contact with a database of  architects through regular eNewsletters. Although small, this type of project can often place a strain on the time and human resources of a small business. Small businesses need to take a structured approach and utilise best practices for project management. There are many good software programs available on the market that can help you manage your project such as MS Project, but if you are a small concern and your lines of  communication are good – a simple project management structure is all you should need. Here is some basic advice about managing your project successfully and completing it on time and on budget. Milestones are essential in developing and completing a successful plan. It sets the plan into  practical, concrete terms with real budgets, deadlines, and management responsibilities. It helps you focus on your project and implement your plan as you complete your project. But it’s important to differentiate your milestones from your tasks and to make sure that your  tasks don’t turn into millstones. Unfortunately, too many people are encouraged to be task-based in their thinking, creating detailed task lists, assigning resources then adjusting these resources to fulfill the task. What is wrong with this picture?  No matter how small your project, your plan should be like a road map – not only does it describe the nature of the project, it tells you what to expect and what alternative routes you can take to arrive at your destination. Milestone Planning is a technique that truly focuses on results rather than tasks. However don’t be mistaken, tasks do have a place in planning; sometimes, a detailed task list is just what we need to estimate how long the project will take. But an over-emphasis on tasks can bring about an unnecessary burden creating a millstone that will eventually weigh you down. When setting your plan a good tactic is to plan for results rather than plan for activity. Focus

on your long-term goal. Now, work backwards from your final goal to set the short term goals you need to arrive at your final destination. Put some bite into your plan listing specific actions to be taken. Each action becomes a milestone. This is where a project plan becomes a real plan, with specific and measurable activities, instead of just a document. You may set as many milestones as you wish, giving each milestone a description: List Building Data Entry  Newsletter design  Newsletter content  Newsletter dispatch Each milestone then needs to be broken down into the number of tasks it will take to achieve that milestone and then assigned the following. Start date Projected end date Budget Person responsible Deadline This milestone plan can now be summarised as a commitment calendar, which lists the major  milestones and who is responsible for each task. Obviously, the more committed the person is to the task, the more successful your project will be. For example, if telemarketing was one of your database gathering tasks, you would assign this to a person with good phone skills and the time available to complete the task. • • • • •

• • • • •

A task is an activity that contributes towards a deliverable, or in this case, a milestone. Completing tasks is a way of measuring your progress, the more tasks you complete, the closer you get to achieving a milestone. Sure, you set yourself dates for fulfilment of your  milestones, but they are not reached simply because the date has arrived. Planning for results rather than activity is the most productive method. The project team should measure results, employee response, and identify any areas for improvement or  corrective actions. A final project report and closing findings and recommendations should be written and submitted to management.

The project responsability matrix represents prokect work packages as lines and all roles or   people involved in its columns. Symbols are used to assign the different functions to the different emplyees and parties involved per line (work package). The following symbols are generally used” C= initiator, Controlling [initiates task execution, monitors its progress] R= responsible for execution [has overall responsability for performing the task] P= participating, collaboration [helps executing the task] D= decision-making [responsible for making necessary decisions relating to the work   package] I= information to [ has to be informed]

In contrast to all previously described task allocation instruments, the responsibility matrix determines collaboration and the flow of information, in addition to the persons responsible. This provided orientation in case of complex work packages.

The bar chart is mainly concerned with two tasks: (a) to visualize the temporal relation of  the individual processes for all project members, and (b) to allow the project manager (i.e. the manager of the project folder) to manage the dates of the individual project processes.

The bar chart is the most widely used scheduling tool and it is also very suitable for  documenting those responsible for each activity. This can be added in a separate column

 between the work oackage titles and graphical bars. When using project management software  programs, further analyses can be shown. Below you can see an example:

Process representation within the bar chart

An individual process of the project is represented by a single coloured bar. Processes with dates that have never been accepted by the project manager (e.g. processes directly after creation) are represented by a thin, lightly coloured bar, whereas processes with dates agreed, i.e. dates accepted by the project manager, are represented by a bold, dark bar. Change proposals for processes with agreed dates are represented as thin bars running within the bold bars. The same goes for delays caused by inter-process dependencies. Additionally, the process responsible for a delay is displayed in a blue font. For simple project members, the bar chart only visualizes deadlines agreed upon and proposals for deadline shifts; project owners are provided with additional management functionality. Dependencies

As project manager you may define dependencies between processes, i.e. you may specify that a process may only start after another process has finished. Select File

Dependencies in the top menu of the bar chart.

The ‘Dependencies’ form shows the existing dependencies for each process. You may define a new dependency for a process by selecting another process from the list and clicking [Add]. Existing dependencies may be removed by clicking the

icon.

 Note that definition of a dependency may lead to a delay in dependent processes with dates agreed upon. This has to be accepted explicitly by you as project manager. Accepting date changes

Besides date changes made necessary by the definition of new dependencies, the project members responsible for a process may also propose a date change for their process on their  own). As a project manager, you have to decide on all of these date change proposals. Select File Accept Dates in order to view the dates of the project as a whole and of the individual processes. The table opposes dates agreed upon and date changes suggested  by the process responsible. Delays in dependent processes are indicated in italics, while the originating process is marked with an asterisk (*). When deciding on proposed date changes or delays due to dependencies, you may o [Accept Dates], o [Reject] or  o again [Change Process]. You may also [Accept ALL changes]. With a corresponding setting, project members will be notified of these actions per email. If the respective option is configured for your BSCW server, process owners may acknowledge the acceptance of date changes proposed. Versions

Every [Accept Dates] action lets BSCW store the previous state of the complete project and its processes as a project version in a history archive. In order to view a table of all versions of  the project, select File Versions in the top menu of the bar chart. Clicking the corresponding bar  chart icon displays the bar chart of the version selected. You may also delete project versions if this is configured for your BSCW server. Select File Delete Versions in the top menu of the bar chart to view a table of old pro ject versions. Check the versions you want to delete and confirm with [OK]. Settings

The project manager may change some project settings concerning the bar chart representation and the email notification about date actions. Select File Settings Preview to change the preview period for project members, i.e. the future period of time for which the bar chart is displayed to ordinary project mem bers. In the manager view, the preview period is indicated by a somewhat darker background.

Select File Settings Column Width to change the display width of the text and the bar  column in the bar chart. Select File Settings Notifications to activate or deactivate email notification of   project members concerning acceptance, rejection or change of process dates by the  project manager.