(, 2007)

| | Alternative name(s) | | Description | Agile values: | Manifesto (2001) | ‍‍‍‍ | Agile Manifesto Principles | Other Agile principles | Agile practices | Discussion | Links from this KA to other KAs | References | External links

Alternative name(s)

‍Assumption Management, enterprise risk management (Chapman,2003)


PMBOK Guide defined the risk management as the action or practice used to cope with risks. Project risk management mainly concerns how the risks positively or negatively affect the [[#|process]] or final deliverable of the project. It includes certain processes: risks planning, risk identification, risk assessment, development of risk responding strategy, monitoring and controlling risk (Kerzner, 2009).

Traditional risk management often requires an experienced and highly skilled [[#|project manager]] and need to collect views through various methods to create a comprehensive risk [[#|register]]. Then the risks will be evaluated and prioritized for responding plan. All this processes highly rely on the ability of the PM and each functional team [[#|spend]] numerous time and effort preparing the detailed ‍plan, ‍while‍ agile risk management is an emergent approach (PM Hut, 2013).

Agile values:

Manifesto (2001)

  • Working software over comprehensive documentation, frequent [[#|delivery]] of working products important for reducing the risk and uncertainty and increasing learning about the process and the product under development.
  • ‍Individuals and their interactions over process and tools‍
Communication between individuals plays a key role in strengthening interactions among team members. Agile methods set regular iteration of review, such as pair programming and daily meeting, to facilitate communication. Besides that, agile management advocate the respect for the contribution of each team [[#|member]], communicating with truth, transparent data, actions, and decisions and also commitment towards team’s goal (Sutherland, 2012). When bringing this aspect to risk management, individuals at different level of the project could have more chance to share information with others and the information will be delivered more directly. Transparent process and honest communication will allow members speak out their own voice freely and eliminate concerns over undertaking responsibility.
  • Customer collaboration over contract negotiation
Agile management allows customers to provide feedback on the deliveries at a regular interval because it divide the final deliverable into small [[#|package]] to deliver. It actually involves the customers in to help the agile team to revise the risk plan and [[#|control]] the risk reaction [[#|practice]].
  • Responding to change over following a plan
Continuously feedback from customers mitigate the risks of requirement changes and all agile approaches have build-in process [[#|to make]] changes based on the feedback from customers. This avoids the risks of unexpected project results by customers.


Agile Manifesto Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Nofal et al. (2005) indicates that one of Juran’s trilogy in quality management is quality improvement to ensure customer’s requirements are met continually, by embedding quality in the organisation.This principle can be linked to PMI approach to risk management, which is a continuous process of identifying, analysing, responding, monitoring and controlling product risk, to achieve its main objectives. That is, creating a method that will help to manage the identified product risk, in order to deliver valuable product that will satisfy the customer (FSA, 2006). PMI project risk management achieves this by involving stakeholders in the plan risk management process at the planning stage of the project (PMI, 2013:309).
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. The Agile process permits continuous interaction of the product owner and the project team, this has an impact on risk management (Project Management Journal, 2013). According to Kerzner (2009), risk management process is conducted throughout the life cycle of a project. The scope of a project may change. For instance, a customer may request changes or modification to specification/requirements. When implementing a project, any change introduced in projects must go through the proper change request procedure even in late development, a risk assessment must be carried out on the change and its impact on the project. That is, risks are identified and then prioritized (Platinum edge). Risks with the highest score or the risk highest to the customer at that time will then have an appropriate planned response in place. Not all changes are implemented in a project. The Change Control Board (CCB) makes a decision to approve or reject the request (Tayntor, 2010). Thus, only positive changes that are beneficial to the customer are introduced on the project (PMI, 2008).While agile methods are focussed on exploiting a positive risk to give the customer an edge, PMI approach is more focused on mitigating negative risks to avoid scope creep or feature creep (in software development). (PMI 2013; 347)
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. During the implementation of a project to deliver a product or deliverable, there is constant communication between the project manager, project team members, project sponsors and all stakeholders. This helps to prevent risks. The project manager also ensures that the product produced is in line with the customer requirements. Also, the project manager and project team can also clarify any queries they may have about the product (PMI, 2008).
  4. Business people and developers must work together daily throughout the project. The principles of working together with other people as a team underpin how individuals operate, as managing a project does not just mean acting alone or as an overseer, it means involving all potential stakeholders throughout the work to ensure the project succeed. This principle can be related to project risk management, because risk is one of the project tools and techniques that require teamwork and processing of information between developers and business people, as well as receiving feedback's from both sides, in order to create the FMEA (Failure Mode Effects Analysis) and initial risk assessment of the project (Farrington, 2010).
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.This principle does not support the traditional plan driven approach, because projects are built around the Iron triangle, that is cost, time and scope.Individuals are identified as part of the entire project team and some motivational theories are recommended to get the work done
    (Vaishampayan, 2014). Agile and the PMI approach are similar in this respect . Governance structure within a project team permits for trust, respect and accountability. The roles and responsibilities of individuals within the team are clearly stated. This enables team members to be aware of their responsibilities and fulfil their individual roles, to get the job done. Also, team members get the right support from senior levels of management (stakeholders, project managers, project leaders or team leaders) during a project (PMI, 2008).
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. This principle relates to the PMI Project risk management knowledge area because during the initiation phase of a project, brainstorming technique is one method of risk identification where project team members have a face-to-face conversation to conduct an initial risk assessment on the project identifying as many risks as possible within a short time (Zwikael & Ahn, 2011).
  7. Working software is the primary measure of progress. The PMI approach to risk consists of six processes: identifying risks, performing qualitative, and quantitative risk analysis, planning risk responses and controlling risk. This is documented in the risk management plan. (PMI, 2013; 316). The Risk Management Plan defines the risk management team for each activity and clarifies their roles. In agile, however, by using working software as a primary measure of progress in agile, the risk is by default with the developer, but it is also shared by the customer or product owner. This means that risks are hauled forward and confronted early. (Moran, 2014).This also implies that the risk is reduced as the project progresses as in any project lifecycle albeit comparatively quickly as result of the iterative nature of agile processes. This may be seen as a concentric cyclical risk management process inside the agile iteration process. Risks also decreases early in the product lifecycle as the software is improved. This will reduce the risk of scope creep as the goal is focussed on achieving a working software.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. In agile, the project or product team targets a work pace that they are able to sustain indefinitely, the emphasis being on a 40-hour week with no overtime. Beck (2000) argues that that developers want to be fresh and eager every morning, and tired and satisfied every night. Cohn (2005) further suggests that this leads to higher-quality code and fewer bugs. This means that resource risk due to overworked staff and quality risk is already being mitigated by default. On the other hand, PMI approach to risk Management is linear up to the risk response planning stage but takes an iterative approach after, as new risks are identified during monitoring and control.
  9. Continuous attention to technical excellence and good design enhances agility.
    Effective risk management is vital to project success, and is a continuous process running throughout the project lifecycle. Risks can be identified, assessed, responded to and controlled in an easier manner if constant attention is paid to ensuring technical excellence and good design.
  10. Simplicity — the art of maximising the amount of work not done — is essential.
    During the implementation of projects, the project team members and project manager focus on delivering the project requirements according to project scope. This maximizes the amount of work not done and it allows products or services to be delivered more quickly. Projects are managed according to size and complexity of the work (Watt, 2012). This means including only on the necessary component of the product and simplicity increases the delivery of the product (Canty, 2015). PMI (2008) addresses this by managing risk around scope, this means identifying and prioritising only risks that will pose threat to the project.
  11. The best architectures, requirements, and designs emerge from self-organising teams. A risk manager may be appointed to lead the team on large projects (Cadle & Yeates, 2008). A strong leader is a major success factor. In an agile environment on the other hand, level two and three staff are of a much higher percentage than level one thus enabling self organising teams higher level of autonomy. (Boehm and Turner, 2003).
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. This principle relates to Project Risk Management, because it supports learning from experience. Lessons learnt from different past projects can be incorporated into a new project and identified risks can be managed at an acceptable level, after the initial risk assessment is conducted by the project team. Risk are identified throughout the various phases of the project (Kerzner, 2009). Although projects are unique, behaviour towards common risks can be adapted from previous projects, and adapted to aid the project teams' effectiveness. Also PRINCE2 methodology, supports team members to learn from experience, that is lessons are sought, recorded and actioned throughout the project lifecycle. Lessons are identified when progress are reviewed. Learning lessons requires taking actions execute improvements. Actions may apply to current or different projects.


Other Agile principles

  • Working software is the primary measure of progress
‍Risk management has been an integral part of software development. Security is the crucial part of the product. Risk management must be introduced at the beginning of the project and the risks must be evaluated throughout the development of the project. Agile development is based on short cycles and it is a flow chart of programming code to the client. Risk management is a very old slow process and a traditional process as well. Agile processes are not heavy documentation process while risk management is heavy documentation process.

  • Continuous attention to technical excellence and good design enhances agility.
‍The model has risk board which is calculated by multiplying and probability. The biggest problem with the board is assumption of probability and in some cases it is very hard to access the probability. If the problem continues then board will be of simple calculation such as high, low and medium. If there is no risk found, instead of risk board, sticky notes come as a replacement to the risk board. The sticky note should have name of the person to which risks is associated, description of the risk and responsible for implementing the feature. And are two volume namely red and yellow sticky notes. The red one is for risks and yellow one for solution for the risk (Ylimannela, 2010).

Agile practices

‍The main goal of project risk management is to increase the percentage of probability and positive effects of the project and reducing the adverse effects of the project. In traditional practices, risk identification involves group member meetings, documents, high probability assumption and heavy documentation work which is done in a program called as spread sheet. in agile practices, planning meetings. In traditional practices, the risk management uses quantitative method and predict high degree of probability and in agile practices uses qualitative method and increase the immediate [[#|delivery]] of the project (Sliger,2006).‍


‍Traditional risk management often requires an experienced and highly skilled project manager and need to collect views through various methods to create a comprehensive risk register. Then the risks will be evaluated and prioritized for responding plan. All this processes highly rely on the ability of the PM and each functional team spend numerous time and effort preparing the detailed plan. While agile risk management is an emergent approach (PM Hut, 2013). During frequent iteration and utilization of real working software, risks can be detected in the earliest time and quickly, like daily meeting. And the responsibilities for detecting and mitigating the risks are taken among self-directed teams. Now the risks are treated by a whole-team and reactive view.
During frequent iteration and utilization of real working software, risks can be detected in the earliest time and quickly, like daily meeting. And the responsibilities for detecting and mitigating the risks are taken among self-directed teams. Now the risks are treated by a whole-team and reactive view.

Cohn (2010) indicated that concerns are raised as agile tend to ignore risk management. If a project adopt agile approaches, explicit risk management could be unnecessary because agile requires frequent iterations over working process and emphasis on testing via working software. These methods help to eliminate the risks that could lead to a failed delivery and thus, many agile project probability neglect explicit risk management. Moreover, for these projects, the cost could outweigh the likely savings form explicitly risk management.‍‍

Links from this KA to other KAs

‍Risk management is related to Assumption Management, since Risk identification involves making assumptions of possible events that will occur in the project's future.Their process are familiar such as evaluating uncertainty's effect and plan responsive action.


Beck, K. (2000) Extreme Programming Explained. 1st Edn. Addison-Wesley [Online] Available at:!/search?bookMark=ePnHCXMwRV1BCsIwECx4qYp_yAcqzaZJGq9S8QHitaTJBgRbeqjQ57vbVryHnIbdmdld5pCdPO9mD9NywxV3pISAeYVZ5ls5VT9lHKeh5BXBifAD-c8T4X5W13qfnZt5YntMbEtKPZVxgfP4JrWMUVwE9qQlA4r1OvaYPW_N43ovtvyAwivrQBfSlzK4qGMoO2q0MqFFIExbr1JKWKG3PkgwiZ8Rf0NZo4PoEvVJBa7jLPX14_8VRPsZXgNHJbd9HNvVMdBM00lXqC-OTkaf [Accessed 8th Feb, 2016]

Cadle, J. & Yeates, D. (2008) Project Management for Information Systems. 5th edn. Essex: PEARSON Prentice Hall. [Online] Available at:,+a+project+manager+or+risk+manager+can+be+appointed+to+lead+the+team&source=bl&ots=_DMqo1Qpgo&sig=HBrK3Qciar09CbFSPRNVESIp5xQ&hl=en&sa=X&ved=0ahUKEwiR2ZWU4ObKAhWG2hoKHRHZCuwQ6AEIKTAC#v=onepage&q=During%20the%20project%20risk%20management%20process%2C%20a%20project%20manager%20or%20risk%20manager%20can%20be%20appointed%20to%20lead%20the%20team&f=false [Accessed: 07 February, 2016].

Canty, D. (2015) Agile Concepts for Project Management. IT Performance Improvement. [Online] Available at: [Accessed: 10 February, 2013].

Chapman, C and Ward, S(2003) Project Risk Management :Process, techniques and insights. 2nd edn, New Jersey: John wiley & Sons, Inc.

Cohn, M. (2005) Agile estimating and planning. Pearson Education [Online]!/search?bookMark=ePnHCXMw42LgTQStzc4rAe_hSmGEHHJjaGxuaGRmbGLODDrWxtgQdLA5qCLiAo1qAOsNYMrhgA2NgM7UAiYUTgZZx3Rg1lAAHTcBar7lpSsAe9cKBdDbfLgZpN1cQ5w9dIGeKymOhw53xAPrJFNz0IG_ihDZ4sQ0YK8zHtRmLY5HcYoRfhMAXhQ2jQ [Accessed: 8th Feb, 2016].

Cohn, M (2010) Managing Risk on Agile Projects with the Risk Burn-down Chart.
[Online] Available at: [Accessed: 10 February, 2013].

Farrington, J. (2010) Importance of teamwork project smart article. [Online] Available at: [Accessed: 08 February, 2016].

Financial Service Authorities (FSA) (2006). Treating customers fairly- towards fair outcomes for customers. (Online) Available at: (Accessed: 10 February, 2016].

Kerzner, H (2009) Project management a systems approach to planning, scheduling, and controlling, 10th edn, New Jersey: John Wiley & Sons, Inc.

Moran, A. (2014) Agile Risk Management. Dordrecht: Springer International. [Online ] available at: [Accessed: 8th Feb, 2016].

Nofal. A., Omaim N. A. & Zairi, M. (2005) ‘TQM Critical Factors: The Recipe for Successful Implementation’. International Journal of Applied Quality Management. 2(2). International Management Journals. [Online] Available at: [Accessed: 10 February, 2016].

PMI (2008) A Guide to Project Management Body of Knowledge. 4th edn. Pennsylvania: Project Management Institute Inc.

Project Management Institute (2013) A Guide to the Project Management Body of Knowledge (PMBOK Guide) 5th Edn. Newtown Square: Project Management Institute. pp. 309-349.

Project Management Journal (2013) Agile Project Management: Essential from the Project Management journal. [Online] Available at:,+even+late+in+development.+Agile+processes+harness+change+for+the+customer%27s+competitive+advantage&source=bl&ots=G1WXpah3jL&sig=T1oxlz6IMptmZm4Irkh6u0HpKSU&hl=en&sa=X&ved=0ahUKEwidrIW46ezKAhWESBQKHQ08A6IQ6AEIMDAC#v=onepage&q=how%20does%20project%20risk%20management%20relate%20to%20Welcome%20changing%20requirements%2C%20even%20late%20in%20development.%20Agile%20processes%20harness%20change%20for%20the%20customer's%20competitive%20advantage&f=false [Accessed: 09 February, 2016].

Sliger, M (2006) Column info : Relating PMBOK Practices to Agile Practices--Part 3 of 4 . [ONLINE] Available at: [Accessed:10 February, 2013]., (2007). PM Clinic | Building Better Software. [online] Available at: [Accessed 23 Feb. 2016].

Sutherland, J. (2012) Agile Principles and Values
[Online] Available at: [Accessed: 10 February, 2013]

Tayntor, C. B. (2010) Project Management Tools and Techniques for Success. Boca Raton: CRC Press.


Watt, A. (2012) Project Management. [Online] Available at: [Accessed: 16 February, 2016].

Ylimannela, V. (2010) A model for risk management in agile software development [Accessed: 11 February, 2013]

Zwikael, O & Ahn, M. (2011) ‘The Effectiveness of Risk Management: An Analysis of Project Risk Planning Across Industries and Countries’. Risk Analysis. 31(1) pp. 25-37 [Online] Available at:
[Accessed : 8th February, 2016].

External links ......Risk management by APM ..... PMBOK approach to risk management