Agile versus PMBOK – Which is Best For You?

PURPOSE:    There is a popular trend for organizations to become agile.  I believe some of them do not even understand what that means.  This document assesses the strengths and weaknesses of both to see which is best for yours.  The best result may be a hybrid.

This examination is not meant to be definitive, but rather an examination of fundamental issues.



Many would point to the tremendous superiority of PMBOK budgets over Agile budgets and they would be correctIF PMBOK budgets were determined correctly.  From experience, PMBOK budgets are almost NEVER determined correctly.

PMBOK projects, if managed properly, have a budget based upon the work to be done.  Agile budgets have little relation to the work necessary because the work is defined as the project progresses.

Proper Components of a PMBOK Budget

  • WBS (Work Breakdown Structure).  The rolled up costs of all activities, work packages and milestones determine the cost of doing the actual work.   All planned personnel related expenses including training, recruitment and incentives, procurements, etc. should be included.
  • Risk Reserve.  The EMV (Expected Monetary Value) of risk at baseline.  This is calculated as the impact of each risk should they happen multiplied by the percentage likelihood of those risks occurring. 
  • Project Management Cost.   This should be calculated as the weekly project manager cost multiplied by the number of weeks in the critical path plus time for closing activities.
  • Initiating and Planning Cost.  At baseline, all costs incurred to that point should be added to the project as initiating and planning costs.
  • Capacity Planning.  The impact of non worked time and non productive work time must be addressed.  This impact may be huge.





Agile budgets are based upon burn rates (cost per week) with a hopeful approximate time frame to complete the project such as 1 year, 2 year, etc.  Organizations can improve estimates over time, but the truth is that agile budgets are much less accurate because scope is never completely defined.


Similar to the budget, PMBOK schedules COULD BE much more accurate if they are based upon the work necessary.  Agile schedules are gross estimates because it is established without approved scope.

For a PMBOK schedule to be accurate, it would need to be 1) based upon the work defined in the WBS (Work Breakdown Structure) and displayed in the Network Diagram, 2) the total amount of hours required should be divided by the percentage of non work and non productive time determined by capacity planning and 3) the ETV (Expected Time Value) of risk should be added to the schedule as a risk schedule reserve.

Similar to the budget issue, PMBOK schedules are rarely if ever generated correctly.


PMBOK metrics “should” compare precisely how the project is progressing compared to the budget and schedule based upon Earned Value.  At any point in time, one should know metrics such as CPI (Cost Performance Index), SPI (Schedule Performance Index), ETC (Estimate to Complete), EAC (Estimate at Completion and BV (Budget Variance).

Agile metrics involve Velocity (likelihood of meeting agreed to release dates) and Trend Analysis for defects, change requests and clarifications.

Once more, PMBOK holds a distinct advantage.  However, PBMOK metrics are extremely rare.


Once more, PMBOK would hold a distinct advantage IF project risk management were performed correctly.  It rarely is.  Also, PMBOK would be greatly enhanced if, as introduced in the Schedule section above, it prescribed the ETV (Expected Time Value) of risk and added that to the schedule.


PMBOK projects have a definite budget and schedule and defined work – so there is a definite ending of the project.

Agile projects have no specific scope and therefore could morph into regular work.  For example, an agile project may produce a corporate website and never end because the website could be constantly tweaked as new functionality will continuously be introduced.

For these reasons, Agile projects could go on forever and get to the point where the value of project delivery exceeds the ongoing cost.  This is rarely addressed.

Project Selection:

Project selection is generally the result of an ROI (Return on Investment) perspective.  In PMBOK, when the budget is completed –  the budget figure SHOULD replace the estimate and ROI re-examined in a “go – no go” way.  This is RARELY done.  In Agile it is NEVER done nor POSSIBLE.


Regular Useful Code Releases:

PMBOK projects have a completed product at the project’s completion.  Often the product is ready to launch after it is no longer needed.  Precious resources are wasted.

Agile projects continuously provide value.  This is an enormous advantage.

Easily Modified as Business Climate Changes:

As market and competitive moves become necessary, Agile projects can easily adjust to meet the new situation.  PMBOK projects are much more awkward and slow to adjust.



Best of Both Worlds

  • Plan the project from a PMBOK perspective.
  • Define Milestones as Releases – perhaps two week intervals and with work packages and activities defined to push them into production.  Milestones relate to backlog items and work packages and activities translate into stories.
  • Milestones can be re-sequenced based upon changing priorities.
  • A robust and simplified change management process must be adopted to accommodate the changing business landscape.
  • A serious budget and schedule can be generated and metrics used.  Changes will still be measured in metrics because Earned Value would continue to be generated.
  • There would be a definite beginning and end.  Changes could be approved based upon ROI (Return on Investment).
  • Project selection can be based upon ROI with the budget number replacing the estimate and recalculated to determine a “go or no go”.

There is no reason PMBOK and Agile should not be combined.  It would certainly result in improvements for business.  However, for these to be combined successfully, business can no longer lean on project management organizations that do not understand or utilize best practices.