Tuesday, May 04, 2004

Project Tasks & Action Plan

The project master plan must address how we plan, organize, and control all the work activities to meet our goals of finishing the work on time, within budget and conforming to the quality standards as specified. One important point before planning is that we do not want to do more than necessary to satisfy customer needs, since that is wasting money. On the other hand, we should not do less than necessary, or we may lose the customer.

Once the project manager and his team is chosen, the project team will face the most challenging part of project management: the planning and control phase, to bring the project to completion – on schedule, within budget and in compliance with the quality standards. What is needed is a good basic planning before commencing a project and the approach taken must allow management the flexibility to respond to, and even turn to advantage, the unexpected changes and events that will inevitably occur.

The next stage is to allocate the tasks to different people in the team and, at the same time, order these tasks so that they are performed in a sensible sequence. Task allocation is not simply a case of handing out the various tasks on your final lists to the people you have available. The allocation of tasks should be seen as a means of increasing the skills and experience of your team - when the project is done, the team should have gained.

In simple terms, consider what each member of your team is capable of and allocate sufficient complexity of tasks to match that (and to slightly stretch). The tasks you allocate are not the ones on your finals lists, they are adapted to better suit the needs of your team's development; tasks are moulded to fit people, which is far more effective than the other way around.

Sometimes tasks can be grouped and allocated together. For instance, some tasks, which are seemingly independent, may benefit from being done together since they use common ideas, information, and talents. One person doing them both removes the start-up time for one of them; two people (one on each) will be able to help each other.

The ordering of the tasks is really quite simple; although you may find that sketching a sequence diagram helps you to think it through (and to communicate the result). Getting the details exactly right, however, can be a long and painful process, and often it can be futile. The degree to which you can predict the future is limited, so too should be the detail of your planning. You must have the broad outlines by which to monitor progress, and sufficient detail to assign each task when it needs to be started, but beyond that - stop and do something useful instead.

Once we have a clear understanding of the project, we can then describe it as a set of simpler separate activities. If any of these are still too complex for you to easily organize, you break them down also into another level of simpler descriptions, and so on until you can manage everything. Thus your one complex project is organized as a set of simple tasks, which together achieve the desired result.

The reasoning behind this is that human brain can only take in and processes so much information at one time. To get a real grasp of the project, you have to think about it in pieces rather than trying to process the complexity of its entire details all at once. Thus each level of the project can be understood as the amalgamation of a few simply described smaller units.

In planning any project, you follow the same simple steps: if an item is too complicated to manage, it becomes a list of simpler items. People call this producing a work breakdown structure (WBS) to make it sound more formal and impressive. Without following this formal approach you are unlikely to remember all the niggling little details; with this procedure, the details are simply displayed on the final lists.

One common fault is to produce too much detail at the initial planning stage. You should be stop when you have a sufficient description of the activity to provide a clear instruction for the person who will actually do the work, and to have a reasonable estimate for the total time/effort involved. You need the former to allocate (or delegate) the task; you need the latter to finish the planning.

WBS provides a tool for planning the work activities, including estimates the resources required, estimating the activity durations and costs. The basic aim of a WBS is to split the project into tangible deliverable items. The more work packages we split the project into, the more interfacing with other people, departments, functions or even companies there may be. However the less work packages there are, the harder it will be to budget and estimate resource requirements. It is advisable that a work package should not be more than 7 days of work (for a large project), otherwise, it will be difficult to assign resources, monitor progress and carry out performance measurement.

There are various ways in which people can be organized to work in projects, and the most common types of organizational structures are Functional, Projectized, and Matrix. The structure of the performing organization often constraints the availability of resources necessary for the project.

A good organizational structure conforms to the company’s business objectives. Once clear on the objectives, there are a number of identifiable factors that position a company on the continuum of organizations from functionally based to project based. Creating the ideal structure is likely to be difficult and will require extensive education and good human resource management.

a) Functional Organization

The functional organization is the traditional structure for a large organization bringing together people responsible for each function in the operation of the business. It is known as the Role Culture. The vast majority of people in industry work in such a structure. It relies heavily on systems and procedures, prevents cross-functional communication and is extremely slow to react to change. The organization breeds specialists rather than rounded general managers. The structure is usefully adopted for cost sensitive management of steady state production or technology led products where expertise is more important than timescales.

b) The Projectized Organization

In the Project-type organization, each project is operated like a mini-company. The Project Organization brings a clearer focus on definitive goals; these may be specific to the project rather than general company objectives. The project teams generally have a high commitment to the goals, the project has a flatter management structure than the parent organization and communication is generally excellent. The structure is responsive to all types of change and typically provides the customer with much better services. The organization is best utilized where change is continuous and timescales are fixed and probably tight.

c) The Matrix Organization

The Matrix Organization overlays the functional and the project structures in an attempt to obtain the advantages of both. It is also known as the Task Culture. The functional manager is responsible for the technological expertise and the allocation of his resource to a number of projects. The project manager is responsible for the specification, the time and the cost.

The Matrix structure can achieve the performance benefits of the project organization whilst achieving good resource utilization and giving the individual both an organizational home and a peer group with technological expertise. Its major disadvantage is that it is complicated and promotes conflict.

Many individuals have two bosses, their functional superior and the project manager. It is easy to lay out the theoretical responsibilities of the two however in practice they overlap and conflict. For the system to work effectively, senior management must define responsibilities and mechanisms for solving conflict at the outset of each project. The system brings with it an almost exponential increase in relationships, reporting and communication.

Common Project Pitfalls & Problems

Ned Robbins (Warwick University,2000) listed four fundamental areas as the reasons of projects failure: resource constraints, conflict in projects, unknown, and transience. According to Ned, the main problems are due to inadequate resources, unrealistic deadlines, unclear goals and direction, team members uncommitted, insufficient planning, communication breakdown, changes in goals/resources, and conflicts between functions or departments. Other factors are:

1. Underestimate of the technical difficulty.
2. Non-compliance with procedures.
3. Problems with software project.
4. Inability to control contractor’s work and failure to use specialist staff.
5. Weakness in contract arrangement.
6. Lack of effective planning and control.
7. Interruptions in funding.
8. Escalation in cost.
9. Changing in specification.

Jeffrey K. Pinto (1998) states that technology; configuration management and overlapping design and production are also factors that contribute to project failures. According to Pinto, inappropriate or unproven technology is one of the greatest source of problem in projects. Project managers should recognize that using unproved technology in their project will increase the likelihood of problems, delays, or overruns dramatically.

In the Malaysian construction projects, it is worrisome to find that many design engineers and architects, in their desire to explore new technologies and products (which they have not experience), were prepared to introduce the new technologies and product in their design drawings and specification. The result is that many of these projects ends up a failure, or were delayed dramatically. The experience was helpful as it provides knowledge of those technology usage, but loser was not the specifier and designer, but the owners who engage them, and probably, the contractors whose reputation were tarnished.

Poor control of changes is another major source of project difficulty. Changes often arise from design and poor change control system can cause serious damage to a project. Overlapping design and production, that is concurrent engineering describes implementation of technology before the design is stable and often lead to major cost overruns.

Kenneth G. Cooper described the four main sources of project failure:

 Failure 1: Failure to know what to expect, or Great Expectation.
 Failure 2: Failure to know what to watch, or half-Blank Tape Measures.
 Failure 3: Failure to know what to do (and to do it), or Counterintuitively counterproductive countermeasure).
 Failure 4: Failure to know what’s what, or Lessons Not Learned.

Failure 1 is due to changes, poor product definition, poor or inadequate budget, poor or over aggressive scheduling target (excessively overlapped work stages, schedule pressure, inefficient & costly resource use, and workers demoralized).

Failure 2 is the failure of project managers to take into account the quality of the work done, the release of incomplete or imperfect task products, or the amount of rework that will be required. Kenneth Cooper suggest that project manager can make improvement measure by:

 Acknowledging these weaknesses and set to reduce the disruption of these surprises.
 Actively sought out. Earlier discovery may feel unpleasant at the time is strongly encouraged.
 Prevented as much as possible, that is improving quality in the rework cycle.

Failure 3 is not knowing what to do as a manager of a challenging project or when faced with the prospect of an ongoing project’s missing its target. The prospect of poor management means that managers will seek preemptive or corrective countermeasures. In most cases, the countermeasures will be obvious, intuitive, accepted, almost second nature – and wrong.

Failure 4 is the failure to learn which is the most pervasive failure in all project management. The four different conditions that contributed to and perpetuated this failure is:

 Misguided belief that all projects are different and the lack of understanding of the common dynamics and phenomena shared by virtually all projects.
 Projects are time pressured - rushing to start, and rushing to finish.
 Limited span and career path of project managers.
 Lack of self-esteem in project managers.

According to Juran, a project is a problem scheduled for solution, and that we make the right solution to the wrong problem. To overcome this issue, project managers should write the project’s problem statement to reflect the project objectives.

James P. Lewis list the various causes of project failures:

a) Planning based on insufficient data.
b) A planning group performed planning (not the doer).
c) Project estimates are best guesses, made without consulting historical data.
d) Resource planning was inadequate.
e) People don’t see themselves as working on one team.
f) People are constantly pulled off the project or reassigned with no regard for impact.
g) The project plan lacks detail.
h) The project is not tracked against the plan.
i) People lose sight of the original goal.
j) Senior managers refuse to accept reality.
k) Ballpark estimates (estimates based on sketchy information) become official targets.

No comments: