Agile Planning Onion.png
Source: Agilehelpline (2013)

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

Alternative name(s)

Project Cost Control (Kerzner, 2009); Cost Management (Pinto, 2007); Project costs and Budgets (Meredith & Mantel, 2010).


Project Cost Management (PMI, 2008) is one of the nine ‍‍PMBoK‍‍ (Project Management Body of Knowledge) area, involving project cost estimation and budgeting, and monitoring and controlling the project cost. Sources of project cost include labour, materials, contractors, equipment and facilities, and travel (Pinto, 2007).

Data gathered from project scope, for example, the WBS (Work Breakdown Structure), the Project Schedule, HR (human resource) Plan, Risk Register, and other environmental factors are inputs for project cost estimation (PMI, 2008). Cost estimation methods differ according to industry; for example, in the construction industry, where there is a well established benchmark (Meredith & Mantel, 2010). Two strategies can be used to gather data for cost estimation; Top-Down where senior managers estimate a high-level cost, and Bottom-Up where a detailed cost is estimated by the operational staff. The estimated cost is the project budget, which is the baseline for project cost monitoring and control (Gardiner, 2005).

Cost control is used to compare the actual project cost to the project budget, and is used as a reporting mechanism to relay the project’s progress. Methods such as EVA (Earned Value Analysis) are implemented to measure project cost performance to the baseline project budget (Gardiner, 2005).

Agile values

The Agile approach of Planning iteratively is a quest for value; the quest to achieve the optimal solution (Cohn, 2005). An Agile plan continuously adapts to changes arising due to uncertainties in the project. The planning is more important than the plan; this is reflected in the Agile Manifesto of values ‍‍'Responding to Change Over Following a Plan'.‍‍

Planning in small iterations (small timespan) will enable adaptability to change; requiring minimal project resources. Sticking to a big plan, builds reluctance to change, because it requires additional resources (cost included) to change the big plan. And this reluctance to change may in the long run lead to project schedule and cost overrun.

The purpose of planning a project is: 1) to make investment decisions, 2) to determine resource allocation; 3) to determine if the project is on track to meet its objectives and goals; 4) to improve the decision-making process (Cohn, 2005).

The Agile adaptive planning approach is based on the understanding that the project plan will change as more knowledge is gathered about the project's requirements specification. Therefore, action is taken immediately on the knowledge collected in order to gain more knowledge about the project; simply put, it involves the steps 'Plan-Do-Adapt' (Cohn, 2005).

In XP software development, complexity results in delays and cost overruns, simplicity is crucial for keeping time costs down. (Beck, 2004).


‍Agile Manifesto principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.‍There are two parts to this principles. The first part is the ‘end’ which is customer satisfaction and the other part is the ‘means to an end’ which is the early and continuous delivery. The customer satisfaction is the most important element in this principle, however equally as important is the early delivery part as it generates the necessary feedback thereby providing that awareness of the want of the customers that needs satisfying. In PMI, the element of cost is one of the important factors as it serves as a benchmark for project success (Dennis Lock). Cost is the estimation of the amount of money that is needed to see a project to conclusion. The ‘end’ part of the principle support the fact that project cost management is essential for the customer satisfaction as the conclusion of the project leads to the delivery of the product, service or result that satisfies the want of customer. However, the early and continuous delivery part of the principle only support the knowledge area only when the scope of the project is considered as the adjustment in the delivery of the projects leads to a corresponding adjustment in the cost of the project. Early delivery while maintaining the scope of the project would lead to an increase cost of the project. The principle could be made relevant in its entirety to the knowledge area by the constant engagement of the customer and making sure the customer is aware of the relationship between the project cost, scope and early and continuous delivery. Making the customer aware will ensure accurate description of their needs in the planning stage of the projects.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.‍This principle is all about embracing change at any point in the development process no matter how late the change is. It ensures that the customer is at the heart of the project process. In PMI the principle support the knowledge area through the scope of the project as changes in the scope of project would leads to a change in project cost. For example, if there is a request for a change in the scope of the project in the process of executing the project, the cost of the project will be affected one way or another. The manner and magnitude of the project cost change is determined by how complex the scope change is. However, the principle is fully integrated in the PRINCE 2 as one of the seven themes of the methodology that describe aspects of project management that must be addressed in parallel throughout the project.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.The idea of this principle is the delivery of project that satisfy the customer as soon as possible. In project management, the objective is the successful delivery of project. There are several factors that affects the ‍frequency‍ of project, one of which is the project cost. In both APM and PMI, the principle has a direct relationship with the knowledge area through the scope of the project. ‍The frequent delivery after each iteration will mean more resources like labour and material will be needed to work on the scope to ensure customer satisfaction thereby increasing project cost.‍ As a result cost has to be balanced with project delivery and scope of the project according to the requirement of the customer. Implementing this principle in both APM and PMI practices directly will involve defining the critical success factor of the project with the customer, adequate planning, team motivation on the part of the project team, constant risk management, avoidance of scope creep and most importantly not promising what can’t be delivered. All these are available in PRINCE 2 as a business case. A business case is the main control condition of PRINCE 2 and it provides the justification for the project making this principle the main guidance to the PRINCE 2 methodology.
  4. Business people and developers must work together daily throughout the project.
    Projects are unique and one difficulty faced is estimating. Business people will create estimates based on a number of variables such as experiences or similar projects in the past for example. When the project is under way these estimates will differ but control and monitoring is critical in order to keep costs low. This principle suggests that developers must work daily with business people which helps in terms of monitoring the project costs and identifying new costs because developers will sometimes have better expertise in the field than the business people therefore by working together it helps to control costs. The principle helps to guide the practice as it can allow better estimations to be conducted and in return appropriate budgets are allocated as a result because working together provides a greater input of knowledge and experiences.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    This principle refers to empowerment and motivated individuals which can get the work done as a result of this. In terms of cost management, this principle supports the KA in terms of cost monitoring and control. Motivated individuals who can be trusted to get the work done and on budget are a vital asset to projects. In KA such as stakeholder management for example this principle would be beneficial but in terms of cost management it can be very difficult to trust project teams to get the job done on budget which is why monitoring and control is vital throughout the project to stop escalations in costs. This principle can be used in the KA when there are very motivated teams who seek to complete the project on budget (generally due to incentive contracts in procurement management) but can be difficult to achieve when a set cost is given to contractors who will work less efficiently due to motivation for completion.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    This principle refers to the fact that face to face conversation is the best form of communication method to achieving the desired outcomes/ responses. This principle supports cost management in regards to estimating, budgeting and monitoring and control as communication management is vital to ensuring that accurate estimates are produced, budgets allocated efficiently and project cost monitoring and control is in place to keep it in line with estimates. Face to face conversation provides a clear communication channel whereby other methods such as email may be diluted or misinterpreted in the process which will reflect in the costs as errors are made or resources wrongly allocated due to communication problems. This principle helps guide the practice in the PMI process as it is relevant through the project lifecycle and includes the key stages of initiating, planning, executing and monitoring and controlling whereby communication is very important throughout and face to face conversation helps information regarding costs to be communicated effectively and efficiently.
  7. Working software is the primary measure of progress.This is a very vital principle that relates to the fact that there is nothing that is more of a recognisable standard than producing a software that is working. When developing a software and having a nice coding that really does not work is like having an office with IT experts that don’t deliver a good product.
    It is important to note that developed software will not necessarily but must be delivered regularly but it must be in a good working state. In scrum methodology it obliges that the features should meet a teams defined statement or definition of the word completed. Supremely this should actually mean that the features are deliverable to the customer.
    This principle is relevant to the project team that is commissioned with the sole duty to deliver working software.
    In Agile procedure it endorsed a development that is of a sustainable state. The software developers and the project sponsors or users have to be of a position that they can maintain a steady flow open-endedly.
    Regardless of the above mentioned in Project cost management a lot of valuation, project scheduling are normally carried out together. The cost that it takes to develop are principally the cost of the determination that is put in the work. It is vital to do some cost analysis or estimation right before detailed schedule are written out. The initial estimation can be used to create a budget of the project for the client.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Teams must build trust amongst them and deliver developed software on a more regular basis. A constant stride that is more sustainable without the straining any member of the team to work for a long period of time if not forever. A vital part of the principle is the regular releases of developed software or product. The ability of a project team to deliver a well working product consistently will allow for a better communication/conversation with the end user or customer. Communication in a team aids success. Project cost management principles helps in this principles as its primary concern is with the cost of the resources that are required to complete the project.
  9. Continuous attention to technical excellence and good design enhances agility.This principle relates to the fact that attention to details is important during software development project. In a project team every member in required to pay close attention to the technical brilliance and design of a given product. Building the right product is of a high necessity. A project team must be concerned with not delivering a flimsy product.
    In extreme programming to some very point, scrum does recommend that testing should be carried out to avoid a brittle solutions.
  10. Simplicity — the art of maximizing the amount of work not done — is essential. Cost management involves estimation, budget and control of project costs and it can be supported by the agile principle of simplicity being essential. As this principle focuses on doing only the works required and needed for the success of the project, resources can be channelled towards only works that need doing. Projects have more likelihood of being delivered within budget if they are kept simple and if the amount of work not done without compromising quality can be maximized. Both the cost of a project and amount of work needed for successful delivery can depend on each other it is therefore important to get estimates right and keep cost under control. Cost can be reduced and savings can be made by maximising the amount of work not done, for example when products are being reviewed by customers they may find out that some works that have been planned are not necessary because product is acceptable when tested or checked. Resources will therefore not be wasted on such work.Making changes in stages as the product develops makes it easy to identify the works that does not need doing and is very cost-effective compared to making changes when the product is almost fully or fully developed.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.This principle supports cost management in that when a team is self-organised the team always ensure that resources are properly allocated. Roles/tasks will be allocated according to strength and competency of team members in order to get the best out of individuals. Best people are allocated tasks, this prevents products from being rejected by the customer and cost of reworking or redoing the product or task if it is rejected. A self-organised team is always effective and efficient and members use their initiatives they don’t wait for directions and explore better ways of working and organising themselves. A self-organised team takes collective ownership of the project and do their best to produce the best result.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.This principle aligns with cost management because reflecting regularly on how works can be done effectively ‍could ‍have an impact on use of resources and project cost. Regular reflection and adjustments can be used to control cost and reduce waste of resources. As each iteration is developed, the agile team meet regularly to discuss the progress of the project/process ‍and gather feedback from the customer. ‍This gives the customer the opportunity to assess the product and refine or redefine requirements if necessary before moving to the next stage. The team will learn from the process and improve on how they work together. Regular meetings at intervals helps the team learn what they can do better on the next iteration. The team can also adjusts how members work together to constantly improve team performance.


‍‍Other Agile Principles‍‍

Estimating the cost of a software project is broken down to its simplest unit; i.e. the User Story, this is according the XP principle of Simplicity. Simplicity facilitates Project Cost Management.

A simple method of relating the effort required to develop of one User Story against the other is used to calculate the software project, instead of an elaborate method, which more than likely will require intensive training.
As suggested by Cohn (2005), estimating software projects based on lines-of-code is absolute and complex to calculate. On the other hand, relative estimation is rapid, the accuracy of the estimation increases after a few iterations of estimating the user story.

In this respect, Project Cost Management in Agile is not reserved only for the project manager (PM) as in traditional development. The Product Owner, and Developers are all involved in Project Cost Management.

Lean software development principles deliver fast by eliminating waste; this is an efficient way of Project Cost Management.

Optimise the Whole; optimising the value stream, for example, from the moment a customer places an order to the moment the order is delivered, an optimised value stream reduces waste and saves cost. (Poppendieck & Popendieck, 2006)

Economics is an integral principle in XP; "Make sure what you are doing has business value, meets business goals, and serves business needs. For example, solving the highest priority business need first maximises the value of the project." (Beck, 2004 p14).

‍‍Agile practices‍‍

Planning Small Releases, an essential Agile practice, ensures that the task of planning is divided up evenly over the duration of the project, rather than at the beginning of the project, as seen in traditional project management methodologies such as Waterfall and PRINCE2.

In the XP Planning Game, User Stories are estimated according to the amount of effort required to develop the functionality. This is estimated as Story Point, it is a relative estimate to another User Story that requires the minimum of development efforts, i.e. the Story Point = 1. The cost to build the feature (User Story) is relative to its Story Point value; the higher the value the higher the cost.

The most relevant part of the Agile Planning Onion to Project Cost Management is the Release and Iteration Planning. In the Release Planning User Stories are prioritised according to the business values they will produce. User Stories deemed of high business values are chosen to be included in the Iteration planning, where the cost of developing the features are estimated.

Project Cost Management involves iterative planning, whereby cost management is broken down into its simplest unit, so that is can be better managed. It also mean all project team members are involved in Project Cost Management. This reflect the XP practice of Collective Ownership.

‍‍Lean software development draws from the 'Toyota Production System' of 'non-value added wastes' (Taiichi Ohno, as cited in Poppendieck & Poppendieck, 2006); simply put, removing wasted timeline. From the time a customers' needs are realised until the time the product is release to the customer, Lean software development seeks to eliminate waste. (Poppendieck & Popendieck, 2006).‍‍ This reflect the XP practice of Simple Design as well as Refactoring


In traditional projects the trading-off of the triple constraints; cost, time and quality is the standard practice. It usually involves the trade-off of quality in order to meet both project budget and deadline. According to Cohn (2005), this is because the traditional planning is based on activities rather than features. In addition, the activities are not prioritised by the value they would bring to the customer. This therefore, results in the omission of features important to the customer as trade-offs are made in quality in order to meet the project schedule and budget.

Traditional Project management uses a hierarchical structure as its underpinning, this is most evident when considering Project Cost Management. PRINCE2's 'Project Board' are in overall control of the finances of a project, dictating the cost of the project to the project manager, giving the project manager tolerances that they must not pass. Whereas Waterfall does not allow for change to the project as a whole once the project has begun.

Agile works differently by embracing changes during the project, including changes to the costing of the project. Project Cost Management in Agile is considered in iterations which are structured daily, weekly, monthly and quarterly with all team members active in the decision of how to proceed. Cohn (2005) demonstrates this by the use of a 'Theme-Return Worksheet' in which for each iteration in the project, the team discuss the value of not only the project, but the time required to complete each iteration, the cost of the staff involved in the iteration, and the total revenue to be gained from each iteration, summing this up to give the total cost of the project at hand. Cohn (2005).

On the funnier side of things, this is how you should feel when you omit project cost management; purry kitty here is not looking very pleased.

Cat and Mouse.jpg
Source: eHow (2013)

Links from this KA to other KAs

Benefits Management is related to Project Cost Management in ‍‍that Benefits Management seeks to respond to customer changes in a project.‍‍

Project Risk Management ‍‍seeks to actively change a project the moment a risk is recognised, allowing for code to changed.‍‍ In relating to Project Cost Management, risk is an important part of costing a project; not knowing, foreseeing or responding to a risk swiftly can be costly as it can increase the time needed to complete an iteration, which if not anticipated and corrected can increase the time required on an iteration, potentially increasing the cost of an iteration and later the project.
Project cost management can also be improved by applying value stream mapping practice to the project.


Agilehelpline (2013) 6 Levels of Agile Planning [Online] Available at: http://www.agilehelpline.com/2011/04/6-levels-of-agile-planning.html [Accessed 25 February, 2013]

Beck, K (2004). Extreme Programming Explained: Embrace Change. 2nd edn. Boston. Addison-Wesley Professional.

Cohn, M (2005) Agile Estimating and Planning. Prentice Hall Professional Technical Reference

eHow (2013) Pet Shaming Available at: http://www.ehow.co.uk/slideshow_12246741_disturbingly-funny-craze-pet-shaming.html#pg=1 [Accessed: 28 February, 2013]

Gardiner, P.D. (2005) Project Management: A Strategic Planning Approach. Basingstoke: Palgrave MacMillan.

Highsmith, J (2005) Foreword in Cohn, M (2005) Agile Estimating and Planning. Prentice Hall Professional Technical Reference

Kerzner, H. (2009) Project Management : A Systems Approach to Planning, Scheduling, and Controlling. ‍10th edn. John Wiley & Sons Inc. [Online]

Meredith, J. R. & Mantel S. J. (2010). Project Management A Managerial Approach. 7th edn. John Wiley & Sons Inc

Pinto, J.K. (2007). Project Management: Achieving Competitive Advantage. New Jersey: Pearson Education Inc.

PMI (2008). A Guide to the Project Management Body of Knowledge. edn. 4th PA: Project Managment Institute [Online] Available at: http://proquest.safaribooksonline.com/book/software-engineering-and-development/project-management/9781933890517/the-project-management-framework/3 [Accessed: 22 February, 2013]

Poppendieck, M. & Popendieck, T. (2006). Implementing Lean Software Development: From Concept to Case. Boston, Addison-Wesley Professional.

External links

http://www.mountaingoatsoftware.com/tools Free agile project management tools, which includes Velocity Range Calculator, and Relative Weighting

http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall Agile software development project have a much lower percentage of time and cost overrun as compared to traditional waterfall approach.

http://www.mountaingoatsoftware.com/articles/incorporating-learning-and-expected-cost-of-change Priotising change in order to minimise cost in agile projects