Here’s another way to think about this concept. Consider value driven delivery to be like credits or deposits being paid into your bank account. Risks, or at least risks occurring (issues), are then like withdrawals or charges being taken out of your account. We want to maximize the inflow and minimize the outflow to create the most value.

Eat your Dessert First - Early Value Delivery
Agile methods promote early value delivery. This means aiming to deliver the highest value portions of the project as soon as possible. There are a number of reasons for this approach. First, life is short, weird stuff happens, and the longer you run a project, the greater the horizon of risk for failure, reduced benefits, opportunity erosion, etc. So to maximize success, aim to deliver as much good stuff as soon as you can before things change or go sideways on you.

The second major reason is that stakeholder satisfaction plays a huge role in project success. Engaged, committed sponsors and business representatives who support a project are vital to removing project obstacles and defining success. All project teams are on a “trial” period when they start, as sponsors may not be convinced the team can deliver. By delivering high value early, the team demonstrates an understanding of the stakeholders’ needs, shows a recognition for the most important aspects of the project, and displays an ability to deliver. Results raise stakeholders’ confidence, build rapport, and get stakeholders on board early, creating virtuous circles of support.

Chartering – Chartering in agile projects has the same general goal, but a different level of detail and set of assumptions. The goal of a Charter is still to describe the project at a high level, gain agreement into the W5+ (What, Why, Who, When, Where and How) attributes of the project and give authority to proceed. However, since agile methods are often used on projects with uncertainty around requirements / technology, and high rates of change, there is typically less certainty around scope.

In general agile charters have less detail, are shorter documents, and focus more on how the project will be run than what exactly will be built. This is because when aiming at a static target (unchanging requirements / technology) it is appropriate to plan, plan some more and then execute. In the dynamic and moving target environment of an agile project lots and lots of planning may not be appropriate if elements of the project are likely to change. So, when aiming at a moving target, we need to allow for mid flight adjustments and ensure the processes (prioritization, demos, retrospectives, etc) are in place to allow for them.

Elements of agile that may be different for an organization, for instance, welcoming changes and then prioritization of approved changes into the backlog, should be clearly outlines in the charter. This is especially important if the organization is new to agile and this may be a departure from how changes were handled in the past...


“This article is taken from the upcoming RMC “PMI-ACPsm Exam Prep” guide. Sign-up for notifications and pre-order offers here. This article is protected under copyright © 2011; all rights reserved. Except as permitted under the United States Copyright Act of 1979, no part of this article may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of RMC Publications, Inc. You can link to the article here from another website, but not reproduce the content elsewhere.”