I have read and understood the rules on cheating, plagiarism and appropriate referencing as outlined in my handbook and I declare

that the work contained in this assignment is my own, unless otherwise acknowledged. No substantial part of the work submitted here has also been submitted by me in other assessments for my degree course, and I acknowledge that if this has been done an appropriate reduction in the mark I might otherwise have received will be made. Signed: ...Ben Gillespie..
(for on-line submission it is only necessary to type your name in this space)

MODULE TITLE: MODULE CODE: MODULE DATE:

Managing the Multi-Project/Programme Environment ES9U1-10 12/13 01NR 29th April 3rd May 2013

NAME/NUMBER: Ben Gillespie GROUP: Network Rail

ES9U1-10 12/13 01NR

THE UNIVERSITY OF WARWICK SCHOOL OF ENGINEERING MANUFACTURING GROUP MSc PROGRAMMES POST MODULE ASSIGNMENT MANAGING THE MULTI-PROJECT/ PROGRAMMES ENVIRONMENT

Answer any two questions.

1. In a multi-project environment there is a lot of information. Some of this needs to be shared, sometimes in a summarised form. Identify what is needed, who needs it and who provides it. What reporting routines can systematise and simplify the process? Discuss the role of the PMO in this communication system. 2. Identify the value of adopting a standard set of project procedures in a company and working to a standard project life cycle. How does this potentially work with a corporate philosophy of benefit management? 3. What are the possible causes of variances in Earned Value Management? What are appropriate management actions in response to variances? 4. Discuss the differences between project risk and programme risk, using the course exercise to illustrate some parts of your answer. In the exercise, to what extent should individual project managers be making their own risk management decisions and to what extent is central direction appropriate? 5. How can cooperation between projects be encouraged and conflict reduced in a multiproject company. COMPLETION DATE: To be submitted electronically using the appropriate web-form available http://www2.warwick.ac.uk/fac/sci/wmg/ftmsc/postmodulework/submissions-nr/ and following the guidelines provided in your handbook BEFORE 09:00 on Monday 17th June 2013 from

PLEASE NOTE 1. PMW received after 09.00 will be treated as having arrived on the next working day. 2. Post Module Work which does not reach WMG by the due date will be considered to be late. Penalties for lateness may be applied at the rate of 3% per University working day after the due date, up to a maximum of 14 days late. After this period the work may be counted as a non-submission.
ES9U1-10 12/13 01NR

Managing the Multi Project Environment

Page 1

Question 1

What are the possible causes of variances in Earned Value Management? What are appropriate management actions in response to variances?

1.1

Introduction

In Earned Value Management variance can occur between the budgeted spend and two other measures, the Earned Value, and the Actual Costs incurred to date. In any project there are many reasons why actual costs might differ from planned costs at a given point in time. Due to the relationship between cost and progress, it is often impossible to ascertain which of these is the cause in a particular instance. In a standard Actual Cost vs Budget comparison two possible scenarios, for example under budget due to poor progress and under budget due to unexpectedly high efficiencies present in the same way. This is why Earned Value Management holds so much appeal; understanding the state of a second variable helps the project manager select the most likely cause when more than one is on the table. Fundamentally, EVM is a tool which allows a project manager (or anybody else) to monitor and control progress. In order to perform the control function, it is necessary to understand what the outputs in the monitor stage mean. For this reason, we discuss some of the primary causes of variance, and how they are likely to present in the outputs generated by EVM. These causes tend to fall into three groups:

Estimating effects Reporting effects Operational effects

The following is a discussion of each of the above, including some specific examples and the management practices that can be employed to mitigate against each.

1.2

Estimating effects

Variance in this instance is down to some inaccuracy in the estimate. Things are progressing as they ought to; personnel are working efficiently, few risk events have come to pass, and none have delayed the critical path of the project, and work packages are being completed in the times quoted by their owners. In this case, those people responsible for calculating and recording estimates are likely to be responsible In EVM, variance due to estimating is of particular concern because of the detail required in calculations and because of the level of detail provided in the outputs. There is a tendency to rely on or too easily accept the outputs of an EVM process. Whilst this is necessary to some extent in Ben Gillespie

Managing the Multi Project Environment the data that feeds it.

Page 2

order for EVM to be useful at all, it is important to remember that EVM is only ever as accurate as

Estimates at the start of the project are likely to be inaccurate because of the availability of good data, and the amount of time available for things to change. As the project progresses, and detailed designs are produced, suppliers are chosen etc, it becomes possible to rely more heavily on estimates. Attitudes in the team should reflect the changing value of estimates, and it is down to the individuals using the tools to apply their own judgement, and understand the need to interpret results appropriately. As part of the control phase of EVM, project teams are encouraged to ensure the project sticks to plan. Most projects are made up of multiple work packages, and the danger of utilising a highresolution technique like EVM is that it causes unnecessary panic. Consider the event that a work package on a path other than the critical path is delayed by twenty days, but is still likely to finish within the available float. This event will present in the Earned Value graphs, with the project showing less progress than planned. In this case the project manager ought to be able to consult a Gantt chart, understand the cause, and feel comfortable taking no action. (Goldratt, 1997) talks at length about the alternative case, in which the project manager applies pressure to each project team to stick to schedule regardless of the impact on the critical path. Even without the project managers input it is likely that visibility of the variance might cause work package managers to panic. In an environment like this, estimates are often padded to give the work package manager his own buffer. This means that estimates are either longer than the actual time taken, or that the task is expanded to fill the time available, both of which act to impact the performance of the project as a whole. To mitigate against these issues we can do several things:

Make sure the goals of using EVM are absolutely clear. Variance is used to identify problems which will impact the critical path, not to monitor or manage the performance of each work package (although this is a secondary function, it should be discussed in terms of lessons learned at the end of the project)

Reward accurate estimates and communicate the criticality of each work package to the work package manager so that work can be shared and prioritised to the benefit of the project as opposed to the benefit of one work package.

Train staff in the importance of accurate estimating, and explain that the project buffer is available if a task overruns, and that buffers should not be built into individual estimates. o The way in which late work packages are handles is integral to this, staff must not feel like they will be punished if they fail to meet their own deadlines.

Ben Gillespie

Managing the Multi Project Environment 1.3 Reporting Effects

Page 3

Reporting effects are those which arise because of the difficulties inherent in measuring Earned Value. These are dangerous for the same reasons as estimating effects; they provide no information about operational performance on the project. In fact, unlike estimating, where discovering errors informs functions outside of EVM, reporting effects are of little consequence anywhere but EVM. As such the uncertainty must be made absolutely clear and considered whenever variance is being considered (and in fact where no variance is evident). Integrated baseline reviews should take place regularly to compare progress to the agreed plan. A good management practice is to hold demonstration reviews to avoid some of the problems already mentioned by ensuring that all parties are aware of the purpose and mechanics of EVM. The following techniques are described in the APM Guidelines for EVM (APM, 2008) and enable reporting on a range work for which progress is often difficult to measure. Milestones complete This kind of measurement is particularly useful for keeping track of a portfolio or programme of projects. Teams are likely to be using a lifecycle approach which already features milestones which can be used to set deadlines and track progress. In Network Rail for example the GRIP process is used for all projects, both internal and external. This is a low resolution approach and the reporting frequency should take this into account. It is also necessary to understand that stages are unlikely to take the same amount of time or involve the same people. Refining an estimate or modifying a baseline based on performance to date is unlikely to be appropriate, and deadlines ought to be set in the plan for each milestone, not calculated as a fraction of the total lifecycle. Percentage complete and Equivalent units These two techniques are very similar. Percentage complete requires an expert assessment of the work completed to date, and is best suited to work of a consistent difficulty and predictability. Building a brick wall is a good example. Equivalent units is similar, except it is used in situations where it is possible to count discrete units complete out of a total necessary. It is only useful to provide this level of detail for work packages that take longer than 3 reporting periods (APM, 2008). Using percentage to record level of completion is common because of its convenience, but it is important to realise that only for certain work is percentage complete likely to be accurate, and is the time taken to reach a given percentage useful for predicting the time remaining. Level of effort

Ben Gillespie

Managing the Multi Project Environment

Page 4

This technique is applied to a very particular type of work package; those that are essential for the project to proceed and which are accounted for in the budget, but which do not have a finish date or well defined outputs. Administrative activities are a good example. It is important to plan these activities on the assumption that the BCWP will always equal the BCWS. In this way we prevent these tasks inducing schedule variance, whilst allowing the ACWP to reflect any cost variance. Apportioned effort Many administrative tasks are more accurately tracked using the apportioned effort method. This allows us to take into account schedule variance for tasks for which the duration is certain but which are planned to take place only on a given date (or dates). Inspection is a good example. The precise mechanism by which this happens is beyond the scope of this assignment, but it is important to note that it relies on a reference work package to which the apportioned effort work is tied. Earned value types for material items EV for material is more complicated than it might at first seem. Whilst the value of material is easily assessed, contractual, administrative or financial events complicate the issue. The method chosen for assessing cost and performance with regard to acquiring material resources ought to ensure that the BCWS and BCWP are linked to the same distinct project event, otherwise the physical progress of the material acquisition will not inform EVM, and the perception of performance will not reflect the reality. Modifying the baseline In each of the above we are looking for ways of measuring the progress of work packages, for comparison against a baseline. The baseline is the budget and schedule agreed at the start of the project. Agreeing a baseline involves an iterative process of comparing costs and task durations until the project plan allows it to deliver the specification within the right time and the right budget. If the baseline is unrealistic then EVM will be consistently fail to produce meaningful results, and could cause the project team to act to resolve issues which do not in fact exist, or to strive for impossible targets which is, at best, damaging to morale. We have already discussed the problems associated with estimating. It is important to realise that as the project progresses it becomes possible to estimate with more certainty, and that variances observed at the start of the project will continue to present for the length of the project. These two facts mean that it is often tempting to re baseline a project. This can allows us to let bygones be bygones and concentrate on the performance of the project after a certain point, and to introduce more accurate estimates so that performance can be more fairly monitored. This increases the usefulness of EVM for the particular project, but if done at all should be done carefully. The most likely problem with base lining is that that mistakes are made and the baseline is updated by one or more individuals in the team, in which case the plan ceases to be common to all parties. A proper management system should ensure that the baseline plan is always the authorised plan as Ben Gillespie

Managing the Multi Project Environment

Page 5

it stands and applies to all parties. There should be a process in place that ensures that any changes to the baseline are justified and understood by all parties, and that this is mentioned in the post project review.

1.4

Operational effects

In this section I will discuss a few of the issues that can arise both internally and externally at the operational level to introduce variance. In the event of variance being discovered, a Project Manager will usually be looking for an operational cause. Once estimating and reporting have been ruled out as the causes of variance, a project manager might consider any of the following. Supplier performance Poor performance on behalf of any contractor, supplier or works, can result in a delay to the project or increased costs. There is uncertain here, and a lack of control. In order to plan we make some assumptions and some estimates about the performance of our suppliers. Effective risk management encourages us to carefully evaluate our assumptions, and to ensure that there are strategies in place to handle negative outcomes. Some of the ways to mitigate these risks are listed below:

Contract choice Long term relationship management Stakeholder management Float

Effective project management includes the publication of an Issue Management Plan, useful in times such as these. Effective issue management means that issues can be dealt with before they escalate, and so that there is the maximum possible time and resource available to address it. As a general rule, the longer an issue is left, the bigger an issue it becomes. Team performance When the team is internal, we must still make some assumptions about their capacity for work. These assumptions will guide our estimates and our schedule. Earned Value provides a useful tool for checking our assumptions and data should be collected early on with this in mind. Data from other projects should be stored and used to make predictions when the same size, or similarly skilled teams are employed on a similar task. If efficiency is dramatically different to that which was predicted we ought to look for a specific cause. If there is only slight variance we might attribute this to team dynamics. There are many complex variables involved when putting teams together (Brown & Dobbie, 1999; Maznevski & Chudoba, 2000; Peterson & Smith, 2003), but a good project management system ought to address these, possibly via an HR function. Ben Gillespie

Managing the Multi Project Environment

Page 6

Data Collection Finally, we ought to remember the complexity of Earned Value Management. When EVM is introduced there are many challenges, and one of the most likely cause of any variance is a simple mistake. Ensuring that staff are properly trained, and have the time and inclination to collect accurate data, as well as the culture of honesty and openness necessary to report on good and bad progress, is essential. This can be done through intensive training, frequent reviews, and promotion of the same culture throughout the entire of the company.

Ben Gillespie

Managing the Multi Project Environment

Page 7

Question 2

Identify the value of adopting a standard set of project procedures in a company and working to a standard project life cycle. How does this potentially work with a corporate philosophy of benefit management?
2.1 Introduction

The prevalence of the lifecycle approach to project management would seem suggest that at this point in time, the benefits of standardising project procedures are beyond question. (Kerzner, 2009) offers 16 points to project management maturity, the first of which is Adopt a project management methodology and use it consistently. I agree that the life cycle approach is sound, but would suggest that it becomes more useful as the size of the organisation increases, as staff turnover increases, and as project frequency and complexity increases. A small organisation with a well formed, self contained and experienced team may find that the informal methodology which has emerged over time is more effective, with its unwritten rules and implicit allocation of tasks, than adopting an unfamiliar formal methodology. Equally, for a company, which only embarks upon projects very infrequently, the costs and time involved in introducing a particular methodology may be prohibitive, although there can be no question that the time and money spent on the project itself would be reduced. Larger organisations who embark on projects often stand to gain the most, because fundamentally it is the element of repetition that the project lifecycle introduces, to endeavours that might initially be considered entirely different, which underpins all the benefits that we are about to discuss. Similarly, for those organisations or projects which rely on a high staff turnover or contributions from specialists for less than the length of the entire project, a life cycle approach allows the roles and responsibilities of those team members to be articulated quickly and clearly, decreasing the time taken for a team member to become productive. This assignment focuses on the benefits that can be achieved by adopting a life cycle approach, and goes on to discuss the link between the life cycle approach and benefits realisation.

2.2

The life cycle approach

The APM talks about a project lifecycle as any model that includes roughly similar phases to these:
Ben Gillespie

Managing the Multi Project Environment

Page 8

Concept Definition Implementation Handover

These are the stages of the lifecycle over which the Project Manager tends to have control. Outside of this, there can be considered two further stages that form part of the extended life cycle: Operation Transition As we will discuss later, it is primarily in these two stages that we have the opportunity to ensure that benefits are realised, in line with corporate philosophy. There are many benefits associated with adopting a standard project lifecycle. The APM summarises these quite in just a few short statements, which allude to the broader topics I will investigate in greater detail in the next section:

2.3

The Benefits of a Life Cycle

According to APM (Bolton & Naybour, 2009), the following benefits ought to be expected when employing a project life cycle: Demonstrates clearly the logical progression through the timeframe of a project. Defines activities and outputs for each stage. Provides logical points at which to stop and review progress to date, to assess risks, the expected benefits, and to plan the next stage. Aid understanding of the evolution of a project, which enables appropriate focus on each task. Ensure an accurate picture is painted of resource requirements throughout the project. Provide the initial high level breakdown so detailed planning can be carried out for each phase. Provide an indication of when temporary or scarce resources will be needed, so that inspections or approval can be planned ahead of time, and that external parties can be managed appropriately Allow progress to be measured on projects, which are in many ways unique, which is a form of assurance for stakeholders.
Ben Gillespie

Managing the Multi Project Environment

Page 9

(Kerzner, 2009) expresses in simple terms the contents and properties of most project management methodologies, which support these benefits and which are important to bear in mind as we proceed: A recommended level of detail The use of templates Standardised planning, scheduling and cost control techniques Standardised reporting format for in house and customer use Flexibility for application to all projects Flexibility for rapid improvements Easy to understand and follow Readily accepted and adopted universally Use of standardised life cycle phases and end of phase reviews Based upon guidelines rather than policies and procedures Based upon a good work ethic

(Kerzner, 2009) also lists some benefits, which, like those of the APM, are very succinct. Faster time to market through better scope control Lower overall project risk Better decision making process Greater customer satisfaction increased business More time for value added efforts

I would argue that the latter two are inevitable results, or even the definition of, benefits, rather than specific benefits. The former however are useful, and provide the basis for my own list, which deals with specific management objectives. I will discuss the impact of a project methodology and the lifecycle approach on these next; Risk Management Organisational Learning Information Management Cost and Schedule Control Change Control Benefits Management

Ben Gillespie

Managing the Multi Project Environment 2.4 Risk Management

Page 10

Risk management is a technique which is hard to adopt automatically, certainly the first time you do a project. Behavioural psychologists would argue that people learn best through a continuous process of punishment and reward. If something is done correctly, reward follows, and if something is done badly, punishment follows. This relies on a short time between the action and the consequence, and a clear link between the two. In projects there are two obstacles to this kind of learning; one is the timescales involved, such that actions may not have a visible impact until days or weeks later, and may have no impact on the individual responsible, and the vast complexity of projects which means that determining the responsible party can be very difficult, and that the link is not clear enough for learning to easily take place. The practice of risk management offers even less in the way of behavioural learning; the desirable outcome is in many cases the lack of a particular event occurring, and hence results in no positive feedback. As such, it is only by understanding risk and addressing it thoroughly, and then by reviewing the impact of the process, that its importance to projects can be fully understood. Processes for risk, as well as other areas of management, are one of the best ways of ensuring that a given project pays the necessary attention to the issue of risk despite the competence of the practitioner. These processes also provide a way of standardising the procedure for otherwise unique projects, and allow experienced practitioners to transfer their learning from one project to another. The project lifecycle provides key checkpoints that provide the opportunity to consider risk for a finite set of well defined activities.

2.5

Organisational Learning

The above discussion on risk leads us nicely into one of the more fundamental benefits of the project lifecycle, which is organisational learning. Projects are by their very nature unique, and as we have said, the lifecycle approach is an attempt to recognise that there are similarities between each. As we mentioned with respect to risk, people learn from their experiences, from the mistakes and their successes, and whilst they learn from these automatically when the feedback is received immediately and the link is obvious, the process needs to be artificially stimulated to apply to all aspects of projects. The project lifecycle ensures that the link between various activities is as clear as possible, that the need for and methods for communication between various parties is clear, and that the resources necessary for each activity is clear. The various processes
Ben Gillespie

Managing the Multi Project Environment

Page 11

employed during a project ensure that a plan is made, that revisions to the plan are recorded, that changes are authorised and that the effect of all of this is measured in terms of cost, time and quality. Documenting the process thoroughly is made possible by the specification of roles and processes for this purpose, and the checkpoints specified in the lifecycle ensure that the review process happens at the end of each stage to make the links between activities that will enable people to learn from their mistakes and successes. Because of the standardisation across projects, this information can then be communicated to any project within (and in fact outside of) an organisation, with the individual in receipt of the information able to understand easily how relevant it is to their particular situation. The project lifecycle approach does not attempt to suggest that all projects can be undertaken by following a particular formula, but allows some order to be read into the chaos of a project, which enables everyone to better understand their impact.

2.6

Information Management

Information is key to any project, and must be available to a range of different individuals at different times. A project based organisation will have an information management system which allows users to check documents in and out autonomously. The life cycle dictates when, and to some extent by whom, the information is required and when. These systems enable important documents like the project management plan, the business case and the schedule to be made available to all parties at all times. Using an information system has to be considered carefully; while the benefits in a complex and large project environment are many, an information management system makes the production and access of documents more laborious. For a small company, or an experienced team like the one described earlier, a formal information management process might be overly bureaucratic. For those larger organisations that do need it, it provides consistency in documentation, the ability to use standard templates for contracts, procurement agreements, schedules, work management plans, and other common documents. It provides an excellent audit trail, and the information necessary for organisational learning, as well as access to earlier versions of each document. A good project management methodology will not just address the system for managing recorded documents. Whilst in a small, well established team, communication is often informal yet effective, in a bigger team or the kind of team often established purely for a given project, a communication plan will ensure that lines of communication exist between people who have never met before but who rely on information from each other
Ben Gillespie

Managing the Multi Project Environment

Page 12

to work effectively. The benefits of this include improved efficiency, improved lead time on a given piece of work, less duplication of effort, a more consistent understanding of the project deliverables, and a more positive, less frustrated workforce.

2.7

Cost and Schedule Control

A formal project management methodology and life cycle normally include tools essential for the management of complex projects. These include Work Breakdown Structures, Gantt Charts, dedicated Project Planning software, Estimating tools and others. These tools enable an estimate to be made in terms of time and cost for every part of the project, and for the sum of each to be calculated. The above enables the projects progress to be monitored carefully throughout delivery. More advanced tools such as Earned Value Management are less common, but are very useful and can only be used in projects where data collection is facilitated by the existence of a thorough and pervasive methodology. Without this their implementation is too laborious to be worthwhile.

Ben Gillespie

Managing the Multi Project Environment

Page 13

2.8 Change Control

There are some issues which affect nearly all projects, regardless of their particular intricacies, and change control is one of them. Without a well defined process to dictate how changes are implemented, scope creep becomes a very real issue. Scope creep refers to the evolution of a design beyond that specified in the original plan, and more specifically beyond the requirements of the business case. A change control process dictates who needs to be consulted before proposed changes can be implemented, and who needs to be told once they are. A configuration management system helps keep track of which components are affected by a given change. Both of the above systems can be used in a wide range of systems, and adopting a standard methodology means that they do not have to be designed from the group up for each project. The benefits include time and cost savings driven by the restriction of the scope to that which is required by the business case, the time and cost savings resulting from the adoption of the standard system, and the avoidance of the risk that a particular change is not catered for in another part of the project.

2.9

Benefits management

In the standard lifecycle, benefits management refers to any contribution to the benefits specified in the business case. Completion of the project makes the realisation of benefits possible, but in order to achieve the benefits we have to consider two phases in the extended lifecycle: Operation Transition

Most thorough project methodologies will contain a benefits management plan, which refers to the precise way in which benefits are realised once the project has been closed out. In the past it was seen as the responsibility of the Project Manager to ensure that the outputs of the project were delivered, but more recently it has been considered that the project team ought to facilitate the realisation of the benefits from the products resulting from the project. This means that the project team must consider how the
Ben Gillespie

Managing the Multi Project Environment

Page 14

operation of the product is going to be handed over, compile information which instructs the new users, and ensure that all responsibility can be handed over. The adoption of a project lifecycle and standard methodology facilitates benefits realisation in several ways. Considering the realisation of benefits throughout means the project team deliver the project with a view to handing over quickly and thoroughly. The project team have the most recent, and the most valid information and are in the best position to perform this job. The project lifecycle provides clear checkpoints at which the realisation of benefits can be considered for the preceding and following phases. Finally, the methodology means that a post project review, and every stage gate review, considers success not just in terms of how successfully the outcomes were delivered, but how successfully the outcomes satisfy the need raised in the business case. This makes these evaluations useful not just to the project team but to the project sponsor and to the business as a whole.

General Sources: (Soderlund, Pinto, & Morris, 2011),(Pinto & Slevin, 1988),(Burke, 2003), (Labuschagne & Brent, 2005)

Ben Gillespie

Managing the Multi Project Environment

Page 15

Bibliography

APM. (2008). Earned Value Management: APM Guidelines. Bolton, J., & Naybour, P. (2009). How to Pass the APMP: Your Journey to Professional Project Management. books.google.com (1st ed.). Reading: Parallel Project Management Ltd. Retrieved from http://books.google.co.uk/books?hl=en&lr=&id=daEO5K0JukC&oi=fnd&pg=PA9&dq=How+to+Pass+the+APMP+a+study+guide+(Your +Journey+to+Professional+Project+Management.)&ots=bjWuhhjZB&sig=TF_gv3h-lmWyiq3kS8-bzu6WvR4 Brown, J., & Dobbie, G. (1999). Supporting and evaluating team dynamics in group projects. Retrieved from http://dl.acm.org/citation.cfm?id=299788 Burke, R. (2003). Project management: planning and control techniques. Retrieved from http://www.lavoisier.fr/livre/notice.asp?ouvrage=1352178 Goldratt, E. (1997). Critical chain. Gower Publishing,. Kerzner, H. (2009). Project management: a systems approach to planning, scheduling, and controlling. Retrieved from http://books.google.co.uk/books?hl=en&lr=&id=4CqvpWwMLVEC&oi=fnd&pg=P R21&dq=project+cost+performance&ots=LNoJuvtw2v&sig=ytEBGM7sTWerXAk O_kmlCnbjqnU Labuschagne, C., & Brent, A. (2005). Sustainable project life cycle management: the need to integrate life cycles in the manufacturing sector. International Journal of Project Management. Retrieved from http://www.sciencedirect.com/science/article/pii/S0263786304000687 Maznevski, M., & Chudoba, K. (2000). Bridging space over time: Global virtual team dynamics and effectiveness. Organization science. Retrieved from http://orgsci.highwire.org/content/11/5/473.short Peterson, R., & Smith, D. (2003). The impact of chief executive officer personality on top management team dynamics: One mechanism by which leadership affects organizational performance. Journal of Applied . Retrieved from http://paulmartorana.com/wpcontent/uploads/2011/09/Peterson_Smith_Martorana_Owens_2003.pdf Pinto, J., & Slevin, D. (1988). Critical success factors across the project life cycle. Project Management Journal. Retrieved from http://scholar.google.co.uk/scholar?hl=en&q=project+life+cycle&btnG=&as_sdt=1 %2C5&as_sdtp=#0 Soderlund, J., Pinto, J. K., & Morris, P. W. G. (2011). The Oxford Handbook of Project Management. Oxford Handbooks. doi:10.1093/oxfordhb/9780199563142.001.0001

Ben Gillespie