According a successful one. The project management

According to Buchanan and Boddy (1992), project is “a unique venture with a beginning and end, conducted by people to established goals within parameters of cost, schedule and quality”. Organizations invest into and run projects to achieve a particular aim. In other words, projects help a company to change and evolve. Therefore, it is vital to be aligned with the company’s vision. Company’s vision is an inspirational statement that describes how the company would like to be in the future (Kloppenborg, 2015).

Although companies have different project success criteria, many project managers consider a project as successful if the project’s objectives are achieved within the ‘iron triangle’ of time, cost and quality. (Haniff, 2016)

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!

order now


Figure 1: Iron Triangle (Haniff, 2016)


Figure 1 illustrates the relationship between time, cost and quality. Haniff et al. (2016) state that each constraint is connected with the others and any change will have an impact to, at least, one other (Haniff, 2016). Usually, these constraints are managed by the client. It is the PM’s responsibility, though, to balance the competing ones.

                It is difficult to define what is project success. The notion of what is a “successful” project has been much discussed in the project management field. Many project managers consider a project as “successful” if the project meets the iron triangle constraints. However, a study by Baker, Fisher and Murphy (1983) strongly suggests that the customer satisfaction is an important factor in any measurement of project success.

Moreover, Baker, Fisher and Murphy concluded:

“In the long run, what really matters is whether the parties associated with, and affected by, a project are satisfied. Good schedule and cost performance means very little in the face of a poor performing end product.” (Baker, 1983)


1.1        Waterfall (Linear) vs Agile Project Management

Project managers are responsible for projects from the beginning to the end and have the prowess to deliver a successful one. The project management has been defined by the PMI as “the application of knowledge, skills, tools and techniques to project activities to meet project requirements.” (PMI, 2013).

The process of project management, however, can be standardized and project managers can follow predefined models throughout the lifecycle of a project (Janjic, 2015). These models are known as project management methodologies.

Traditional (waterfall) project management, is an example of a project management methodology. Based on Haniff (2016), projects which are executed with such method are planned in detail from the begging. Once the project plan has been defined, the scope cannot be changed. It is also called Waterfall because each task should be completed in an orderly sequence (Hass). 

Figure 2: Waterfall in Software Development

                Figure 2 illustrates the phases of a software project that follows the waterfall approach. As can be seen, software flows sequentially from the initial requirements to the User Acceptance Test (Delivery). Once a phase is completed, it is assumed that will not be revisited (PMI, 2013). The requirements and design need to be determined for the entire software as the full scope should be defined in the initial stages.

For a project manager, scope knowledge area is very important. It is part of project planning and describes the detailed set of features and deliverables of a project. PMI defines Project Scope as the “The work that needs to be accomplished to deliver a product, service or result with the specified features and functions” (PMI, 2013). In traditional project management, it is important to determine the scope early as it can greatly impact the schedule or budget of the project. In IT and technology projects, however, clients cannot always pin down all the requirements at the early stages.

Over recent years, the agile project management project life-cycle model has been widely adopted in the technology sector (Hewlett Packard Enterprise Development LP, 2015). Moran (2015) describes the agile as a set of principles and practices that focuses on customer value first and favours responding to change over careful planning. Agile uses short incremental cycles (sprints) with focus on continuous improvement to deliver a product or service.   

Figure 3: Agile


As depicted in Figure 3, in agile projects the work is delivered in short incremental, iterative development cycles (or sprints) of anything up to a few weeks. These are repeated to refine the working deliverable until it meets the client’s requirements.

Agile project management has many advantages compared to the traditional project management. For example, in Agile PM, changes can be introduced at almost any stage while in the traditional PM scope changes are not accepted once the implementations phase has commenced. Additionally, agile PM encourages active involvement from those who will ultimately accept and use the deliverable. Therefore, agile allows building a product based on client’s accurate needs. On the other hand, in the traditional PM, if the initial requirements are faulty in any manner, amendments can be costly.

Another advantage of agile is that at the end of each iteration the project priorities and objectives are re-evaluated, which is quite important when the scope has only been defined in high-level objectives at the beginning of the project. On the contrary, in traditional PM, once the project plan has been defined, the scope cannot be changed.


1.2        Risk Management

To run a successful project, regardless which project management methodology you have selected, it is essential to identify potential risks that may affect the project. PMI defines risk as “an uncertain event or condition that has a positive or negative effect on a project’s objectives.”  (PMI, 2013)


Figure 4: Risks over the Project Lifecycle, Source: (Kloppenborg, 2015)


Figure 4 illustrates the relationship between the number and costs of project risks that discovered during the lifecycle of a project. As can be seen, for risks which are addressed early in a project, the cost is the minimum possible because there is available time to re-organize the project’s plans. In contrast, the cost per risk discovered late in a project is the maximum possible. (Kloppenborg, 2015) Additionally, as Kloppenborg describes, most of the risks are discovered during the initiating and planning phase, and as the project progresses, the number gradually decreases till the project is completed.

Although various checklists of risks that may emerge in a project have been created, risks should be organized into a Risk Categorization Framework (Schmidt, 2001). Schmidt et al (2001) state that based on the importance and level of control of a risk we can classify them into four categories in the Risk Categorization Framework; “Customer Mandate”, “Scope and Requirements”, “Execution” and “Environment”.


Figure 5. Risk Categorization Framework (…. journal)


Figure 5 depicts the Risk Categorization Framework. The first square includes customer’s top priority risks. Typically, these factors are out of the PM’s control. However, such risks can be influenced by building good relationships and trust with the customer.  The second square includes risks regarding the project’s “Scope and Requirements” that are often under project manager’s control. Well organized processes are needed when such risks occur as they are high of importance. Risks regarding the “Execution”, such as poor estimations, inappropriate assignment of roles and tasks etc., considered controllable by experienced project managers and perceived as low of importance. Nevertheless, failure to manage such risks will result in poor project outcome. The last category is about risks concern the “Environment”. This category includes general risks existing in both internal and external environments and can affect the project. Such risks cannot be largely controlled by the PM and regarded as moderate rather than high of importance. (Schmidt, 2001) (Keil, 1998)