Organisation Structure

Organisation Structure:

A project organisation is a structure that facilitates the implementation and coordination of project activities and is undoubtedly related to project success. Choosing an appropriate project management structure is crucial as the best system balances the requirements of the project with the requirements of the company. All projects are unique which is why a number of aspects should be considered when deciding the most suitable project structure design such as the organisational environment, project characteristics and level of authority. A project structure can take on various forms with each form having its own advantages and disadvantages.

There are three approaches which consist of:
1. Functional Organisation
2. Dedicated Teams
3. Matrix Structure

Identifying the project structure is only a part of organising the project. In order for the project to be successful, there must be effective implementation and application. This requires ongoing interaction, integration and collaboration among all individuals involved in the project. Having a structure in place facilitates open communication as it defines the levels of authority and the relationships among all project members. This is displayed using a graphical illustration known as an organisational chart. The organisations aim is to promote the interaction of individuals and to achieve the projects goals within the specified constraints of scope, budget, time and quality. 

Examples of organisation structures:

Book Publisher: 

Best suited - Teams operate as separate units under the leadership of a full-time project manager. In a projectised organisation where projects are the dominant form of business, functional departments are responsible for providing support for its team.

Least suited - Matrix structure.

Advertising Agency:

Best suited - Functional organisation. Different segments of the project are delegated to respective functional units. Coordination is maintained through normal management channels. Used when the interest of one functional area dominates the project or one functional area has a dominant interest in the project’s success.

Least suited - Matrix structure.

Consultancy Firm:

Best suited - Matrix structure. Hybrid organisational structure is overlaid on the normal functional structure. There are usually two chains of command (functional and project) and the project participants report simultaneously to both functional and project managers. The matrix structure optimises the use of resources and allows for participation on multiple projects while performing normal functional duties. Additionally, it achieves a greater integration of expertise and project requirements.

Least suited - Dedicated teams.

Progress Status Report

What is a progress status report?

Establishing a progress status report is the last stage in the project monitoring system. Before this can be carried out, organisations must determine what data to collect; how, when, and who will collect the data in addition to, analysis of the data. Usually, a progress status report is designed and communicated in written or oral form.

What does a progress status report contain?

A common progress status report includes the following elements:

·      Progress since last report

·      Current status of project:

Ø Schedule

Ø Cost

Ø Scope

·      Cumulative trends

·      Problems and issues since last report:

Ø Actions and resolution of earlier problems

Ø New variances and problems identified

·      Corrective action planned

Who is the progress report of use to and why?

The progress status report is utilised throughout the organisation as different stakeholders e.g. project team, peers, customers etc. and levels of management e.g. top, middle and lower require a variety of project information. All the people involved in the project have different interests and concerns in mind which is why the progress status reports should be designed for the right audience.

All managers use progress status reports general to overview what is going on in their team. Managers meeting face-to-face with their employees is vital and so is having a written summary of the project aspects that they identify as the most important. Taking senior management as an example, their main interests consist of checking to see if the project is remaining on track in regards to time and cost. If the answer is no, then the next concern is to analyse what went wrong and to identify and carry out corrective action. However, an IT manager is solely concerned about their deliverables and work packages.

A progress status report can be seen as an opportunity for project team members. This allows the members to showcase any achievements and communicate any issues that require the assistance and support of the Project Manager.

Regarding a project, a progress status report is an extremely valuable tool that is used to track, manage cost, increase visibility, identify risk and obtain control. As well as this, it is considered very practicable as it enables individuals to gain knowledge/ experience and helps to drive the projects success.

Project Risk Management

Risk:

A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on project objectives. A risk also has a cause and a consequence e.g. a cause may be a change in scope requirements and in the event that the product has to be redesigned, this uncertainty will impact the cost, schedule, and quality of the project.

The key objective of project risk management:

Risk Management is a proactive attempt to recognise and manage internal events and external threats that affect the likelihood of a project’s success. It identifies as many risk events as possible (risk event), minimises the risk event’s impact (consequences), looks at what can be done before an event occurs (anticipation), manages responses to those events that do materialize (contingency plans) and provides contingency funds to cover those risk events. Figure 1 represents a risk event graph. Risk management can mean different things on different types of projects e.g. for large-scale projects, risk management strategies might include extensive detailed planning for each risk to ensure mitigation strategies are in place if issues arise however for smaller projects, risk management might mean a simple, prioritised list of high, medium and low priority risks.

Figure 1

Risk management process:

There are 4 key elements of a risk management process:

1.    Risk Identification

2.    Risk Assessment

3.    Risk Response Development

4.    Risk Response Control

Risk Identification:

This process begins by generate a list of possible risks that could affect the project through brainstorming, problem identification and risk profiling. It is vital to focus on events that could produce consequences rather than the objectives e.g. team members may identify failing to meet schedule as a major risk but what they need to focus on are the events that could cause this to happen i.e. poor estimates, adverse weather, shipping delays, etc. The focus at the beginning should be on risks that can affect the whole project as opposed to a specific section of the project or network.

Risk Assessment:

After the risks have been identified in step 1, managers have to develop methods or techniques for sifting through the list of risks, eliminating inconsequential or redundant ones and stratifying worthy ones in terms of importance and need for attention. Examples of these techniques are presented in the table below.

Risk Response Development:

When a risk event is identified and assessed, a decision must be made concerning which response is appropriate for the specific event. Responses to risk can be classified as:

· Mitigating – Reducing the likelihood an adverse event will occur or reducing impact of adverse event

· Avoiding – Changing the project plan to eliminate the risk or condition

· Transferring – Paying a premium to pass the risk to another party

· Sharing – Allocating risk to different parties

· Retaining – Making a conscious decision to accept the risk

Risk Response Control:

Risk control involves executing the risk response strategy, monitoring triggering events, initiating contingency plans and watching for new risks. Establishing a change management system to deal with events that require formal changes in the scope, budget, and/or schedule of the project is an essential element of risk control. It is vital that project managers establish an environment in which participants feel comfortable raising concerns and admitting mistakes as well as organising and carrying out repeating risk identification and assessment exercises. A second key for controlling the cost of risks is assigning and documenting responsibility for managing risk.

Risk management & change management process:
A major element of the risk control process is change management. Change management and risk management have an interrelated relationship. A change management system involves reporting, controlling and recording changes to the project baseline. It is crucial that the two process work hand in hand to be prepared and to provide solutions to risk events that may arise. 

Estimating Projects Time & Cost

What is estimating?

Estimating is the process of forecasting, predicting or approximating the cost and time of completing project deliverables. It is the task and responsibility of balancing the expectations of stakeholders and the need for control while the project is implemented. 

There are two types of estimates:

1. Top-down (macro) estimates: analogy, group consensus, or mathematical relationships.
2. Bottom-up (micro) estimates: estimates of elements of the work breakdown structure.

Accurate estimates:

How project managers ensure that estimates are accurate:

Below are a number of points for boosting and achieving the accuracy of estimates:

• Use several people who are familiar and experienced with the tasks to make the estimate e.g. goal is to launch new colour laser printer - depts such as production, design and marketing should estimate.
• Create and use planning documents e.g. specifications and project plans.
• Perform a detailed task analysis of the work to be performed and ensure to treat each task as independent i.e. don’t aggregate.
• Use more than one method to arrive at an estimate and look for a midpoint among all of them.
• Base estimates on normal conditions, efficient methods, and a normal level of resources.
• Use consistent time units in estimating task times by maintain an ongoing “actual hours” database of the recorded time spent one each aspect of the project. This data can then be used to help estimate future projects and to identify the historically accurate buffer time needed to realistically perform the work.
• Use a “complexity factor” as a multiplier to determine whether a pending project is more or less complex than a previous one.
• Identify a set of limitations, constraints and assumptions to accompany your calculations, which would bound the conditions under which your estimates would be meaningful.
• Don’t make allowances for contingencies.
• Add risk assessment to help avoid surprises to stakeholders.

Conditions for preferring Top-Down or Bottom-Up estimates are illustrated in the figure below.

Bad estimates:

How bad estimates can lead to good projects failing:

• False analogies - When project estimates are developed using methods such as expert judgement, one rarely knows what is relevant and what isn’t. 
• False precision - Project estimates are often quoted as single numbers rather than ranges and these estimates are incorrect because they ignore the fact that uncertain quantities should be quantified by a range of numbers.
• Estimation by decree - The people actually performing the work are excluded from the estimating process.
• Subjectivity - Estimates are based on insufficient information or analysis and are “justified” based on gut-feel and other subjective notions.
• Coordination neglect - Projects consist of complex tasks that need to be coordinated and integrated carefully. Unfortunately, the time and effort needed for coordination and integration is often underestimated or even completely overlooked.
• Estimates are cut in order to secure a contract or to make a project more attractive.
• Estimates are provided without a corresponding statement of scope.
• The assumptions used for estimating are never documented, discussed or validated.

Work Breakdown Structure (WBS)

What is a WBS?

A WBS defines the objectives of a project at all levels of detail (hierarchical) and is essentially a map of the project i.e. visual representation of all parts. It can only be formed once the scope and deliverables have been identified.

How is a WBS constructed?

The WBS begins with the project as the final deliverable. The higher elements are used to identify deliverables at different phases in the project and to develop status reports during the execution stage of the project life cycle. Major project work deliverables are identified first; then the subdeliverables necessary to accomplish the larger deliverables are defined. The process is repeated until the subdeliverable detail is small enough to be manageable (top management deals primarily with major deliverables while first-line supervisors deal with smaller subdeliverables and work packages). This subdeliverable is further divided into work packages which is the lowest level of a WBS. Work packages are basic units used for planning, scheduling, and controlling the project (Figure 1). Since the lowest subdeliverable usually includes several work packages, the work packages are grouped by type of work e.g. hardware, programming, testing. 

Why is a WBS constructed?

• Helps to assure project managers that all work elements are identified therefore they can be easily monitored & tracked
• Determines a project timeline and develops a schedule
• Assigns responsibilities and clarifies roles
• Integrates the project with the current organisation - offers an ongoing view for management and team members into how the entire project is progressing
• Establishes a basis for control - accurate estimation of effort, duration, resources and cost
• Offers an ongoing view for management and team members into how the entire project is progressing
• Minimizes the chance of adding something outside the scope of work or forgetting a critical deliverable
• Helps make planning consistent and provides for effective project execution

How can it be used to identify risks?

• WBS helps controls scope creep and prevents work from slipping through cracks. Unnecessary work or anything not seen in the WBS can be eliminated thus it helps the team to focus on the project scope only.
• WBS enables project managers distribute the project budget into defined packages linked to the tasks and check to make sure that the task costs in total don't exceed the total project cost
• WBS ensures no overlap and no gaps in responsibility or resources

Figure 1

WBS example - Structure for building a house (w= work)

Project Definition Phase

The Project definition phase provides groundwork for project planning. The key activities and outputs from this phase are described below, as well as, the risks that this activity minimises. 

Defining a project consists of a number of key steps: 

                                                                               

Step 1:  The project scope is a definition of the end result or mission of the project i.e. a product or service for the client/customer - in specific, tangible, and measurable terms. For example, as a result of extensive market research a computer software company decides to develop a program that automatically translates verbal sentences in English to Indian. A project scopes primary purpose is to define the deliverables for the end user and to focus project plans. Many projects suffer from scope creep, which is the tendency for the project scope to expand over time and in most cases means added costs and possible project delays. By carefully writing the scope statement, scope creep can be reduced.

Step 2: Quality and the ultimate success of a project are defined as meeting and/or exceeding the expectations of the customer and/or upper management in terms of cost, time and performance of the project. It is interesting to note that the interrelationship among these criteria varies.  For example, sometimes it is necessary to compromise the performance and scope of the project to get the project done quickly or less expensively. A project priority matrix is used to identify which criterion is constrained, which should be enhanced and which can be accepted. This is essential when managing trade-offs among the triple constraints and is useful for approaching a problem that must be solved.

Step 3: Once the scope and deliverables have been identified, the work of the project can be subdivided into smaller manageable work elements for the team. The outcome of this hierarchical process is called the work breakdown structure (WBS). The visual representation defines all the elements of the project and establishes their relationships to the project end items. The WBS can be used to define communication channels in many parts of 
the project. The structure shows the work and organizational units responsible and suggests where written communication should be directed. This means that problems can be quickly addressed and coordinated because the structure integrates work and responsibility. This diagram illustrates the major groupings commonly used in the field to develop a hierarchical WBS.

Step 4: The WBS is used to link the organizational units responsible for performing the work. In practice, the outcome of this process is the organization breakdown structure (OBS). The OBS depicts how the firm has organized to discharge work responsibility. The purposes of the OBS are to provide a framework to summarize organization unit work performance, identify organization units responsible for work packages and tie the organizational unit to cost control accounts.

Step 5: Gaining the maximum usefulness of a breakdown structure depends on a coding system. The codes are used to define levels and elements in the WBS, organization elements, work packages, and budget/cost information. The codes allow reports to be consolidated at any level in the structure. The most commonly used scheme in practice is numeric indention. In practice most organizations are creative in combining letters and numbers to minimize the length of WBS codes.

“We can control only what we have planned”

Gartner Survey Shows Why Projects Fail - Lars Mieritz

In the 2012 article, “Gartner Survey Shows Why Projects Fail” Analyst, Lars Mieritz, classified IT projects by size and revealed the reasons behind project failures.

The three classifications:

1.    Small

2.    Medium

3.    Large

The six causes behind IT application project failure:

1.    Functionality issues

2.    Substantially late

3.    Quality issues

4.    High cost variance

5.    Cancelled after launch

6.    Rejected or not implemented for other reasons

Small:

A small project was defined as one with a budget of less than $350,000. These sized projects are easier to maintain, oversee and execute. In order to achieve a lower failure rate, it is essential that projects remain small and do not exceed 6 months in duration. A fascinating pattern emerged when comparing the most recent survey results with previous data gathered. It indicated that small IT projects encounter a one-third lower failure rate than large projects- there was a 20% failure rate observed for small IT projects. (Figure 1) It is interesting that “poor quality” was ranked 3^rd highest as the reason for small IT project failure with 17% of respondents, whereas it was the 2^nd lowest in medium (12%) and large (11%) IT projects. (Figure 2)

Medium:

A medium project was defined as one with a budget of $350,000 to $1 million. Runaway budget costs are behind one-quarter of project failures for projects with budgets greater than $350,000. There was a 25% failure rate noted for medium sized IT projects which was slightly lower but similar to the failure rate of large IT projects which stands at 28%. (Figure 1) In both cases, nearly one-third higher than the failure rate observed for small IT projects. “Functionality issues” and “high cost variance” were both positioned in the top 3 causes for project failure in medium and large sized IT projects. (Figure 2)

Large:

A large project was defined as one with a budget that exceeded $1 million. The failure rate of large IT projects with budgets exceeding $1 million was found to be almost 50% higher than for projects with budgets below $350,000. It is intriguing that as the projects became greater in size, the failure rate increased accordingly. (Figure 1) Across all project sizes, it was evident that “substantially late” was the main reason for project failures, which is not a surprise considering the ongoing nature of projects. (Figure 2)

FIGURE 1

FIGURE 2