Apps

Use the tradeoff matrix to foster collaboration in agile projects

The tradeoff matrix requires the project team to categorize the constraints as fixed, chosen, or adjustable. Discover the benefits of using the tradeoff matrix in agile projects.

While making prudent project compromises and tradeoffs is a critical success factor in any project, in agile projects, there are certain factors that make it more challenging and more crucial.

Linear projects

In a typical linear or waterfall project, the requirements definition process is a distinct and front-loaded exercise, and much of the negotiation over features to be included is done up front. In fact, this early scope definition process, with all feature determinations and "horse-trading" done before any design or development begins, is the defining feature of a traditional project approach. Anyone who has ever worked on a traditional project knows that new features and ideas will arise during the design and development phase, no matter how frosty the "frozen" specifications are; however, in a disciplined methodology, these modifications will be managed by a change control process that will require a detailed impact analysis and the submission of all change ideas to a Control Board for further evaluation.

These controls solve the problem of scope creep (which has always plagued IT projects), but the controls create unintended consequences. The process of capturing the client's changing requirements and developing and documenting an impact analysis and then shepherding that through a Change Control Board is time-consuming and resource intensive. Also, the process is so onerous that people are discouraged from making a change request, which, in the days of frozen specs and linear projects, was considered a positive.

Agile development

The key insight of agile development is that change, while inconvenient for the development team, is frequently beneficial. In fact, openness to beneficial change is the catalyst for projects that actually deliver what the customer wants and needs in a dynamic and turbulent business environment.

One of the key tenets of agile development is transparency. We collaborate closely with the client and other stakeholders throughout the project so that they can see the design decisions we're making firsthand; they can also work side-by-side with us as we grapple with the tradeoffs and the compromises that are a key part of any product development project.

In order to stay true to the agile concept of openness and visibility, I recommend using the tradeoff matrix as an aid to facilitation and discussion when modifying the feature set we're committed to deliver.

Using the tradeoff matrix

The tradeoff matrix is not a new idea, and it's not exclusive to agile development. I first encountered it when training in the Microsoft Solutions Framework (MSF), a software development life cycle promoted by Microsoft for its development partners and internal teams. Although the MSF was originally offered by Microsoft to partners and developers as a program of guidance for development disciplines, it has evolved into an agile-friendly methodology that endorses many of the collaborative, iterative concepts that are common to agile methods.

Every PM is familiar with the triple constraint; that is, the idea that projects are always constrained by schedule (or time), by features (or scope), and by resources (which include money and talent). When any of these elements change, it requires a tradeoff in one of the other components. For example, adding scope typically requires that the schedule be extended or that resources be added, while decreasing time or resources usually means that the feature set must be reduced. I say typically and usually because every PM has experienced the client or manager who insists on changing elements of the constraint without making corresponding adjustments in the other constraints. This rejection of reality by project sponsors is a driving concept behind agile development. One reason we collaborate with the client or sponsor, bringing them completely into the process, is because only they know what they're visualizing for the product. Agile practitioners insist on the sort of transparency that makes it clear to all participants that wishes, threats, or miracles cannot change the fact that additional scope takes time and resources.

The tradeoff triangle (or the triple constraint) is a useful tool for educating clients and sponsors regarding the unbreakable connection between time, scope, and cost. The use of the tradeoff matrix (depicted on TechNet) takes this conversation a step further. It requires the working team to recognize the reality of the project at hand by categorizing each constraint as either fixed, chosen, or adjustable.

  • Fixed constraints (e.g., the drop-dead project delivery date) can't change.
  • Chosen constraints are based on priority choices made by the team and its sponsors. For example, the decision that, for a particular project or iteration, meeting schedule is more important than including all features, and so some features could be compromised out or "de-scoped" if necessary to meet the schedule.
  • Adjustable constraints are subject to negotiation and compromise.

The tradeoff matrix can be used at the project level to document an agreement between the development team and its sponsors that the entire project will be focused on meeting schedule, for example, and that features and resources can be negotiated and changed. It can also be used at the iteration level to ensure that all team players have a consistent understanding of the priorities and possible adjustments to this particular iteration (priorities can change from iteration to iteration, as teams reach the boundaries of schedule or budget, for example). It's also useful at the feature level, when clients are attempting to add features, to remind sponsors of the agreements and priorities set at the beginning.

The tradeoff matrix is often used as an internal tool for conversation and agreement by the development team. In the agile world, however, it becomes a much more inclusive conversation, in which sponsors, managers, and users also participate in the conversation and have a vote in the outcome. In agile environments, tradeoff conversations are run as facilitated work sessions, and the agile PM leads the collaborative team through the process of filling in the blanks to the following sentence:

Given fixed ____________, we will choose a ___________ and adjust ___________ as necessary.

Whether the team is setting priorities for an entire project, an iteration, or a specific feature, the questions are the same: For the particular project element under review, where must we conform to our previous plan, and where is there room for compromise? In an iterative, time-boxed development project, such as Scrum, where, for example, the typical iteration is constrained to 30 days, we'd start with the premise that:

Given a fixed schedule, we will choose a level of resources and adjust the features set as necessary.

Depending on the project and the determinations made by the team, the resources or budget may be the fixed elements, requiring compromise in time or features. The key point is that these decisions are made by the entire team in full view of all so that issues and disagreements can be worked through. Also, these decisions are made in recognition of the reality that, while agile projects are open to change, change is not cost-free, and any modifications in features, schedule, or resources requires adjustment to the other elements of the tradeoff triangle.

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

9 comments
oneal.j
oneal.j

I think; This is too complex, not simple. Why are you making simple ideas complex? Could I propose the following? Solution: Say what you intend in 5-15 words (or less). James

anirbank2000
anirbank2000

pretty good article, we are always making these trade offs based on some constraints. this is putting it down as hard facts on paper.

dianamek
dianamek

Any work complex enough to be called a "project" is too complex for a simple project-level trade-off of cost, time, and scope (features/quality). Cost, time, and quality have to be weighed for each major feature. An example: The new CRM system includes a surname spelling correction feature. Let's say the cost of the system is not tightly controlled, but you might find (too late) that the customer thinks this feature is marginally beneficial for non-English surnames. Although the global marketing group sees some use for spell-checking Chinese surnames, they don't think it will make a lot of difference in their current, tentative entry in the Asian market. In this case, as in every case, it's all about the value of the product -- at the feature level. Agile development focuses at this level through stories. The value of everything to be produced in a scrum is evaluated before starting. The other flaw of triple constraints is that risk is omitted. Risk-aversion is a hidden constraint on many projects. High expectations for the number/richness of features delivered (over cost & time) could involve extreme innovation and high risks. If the customer is risk-averse but highly motivated, risk trade-offs need to be made at the feature level.

guerrerag
guerrerag

I'd have to agree with the other commentators that the triple constraint is actually still very relevant, although I'd have to say that quality and risk should be added to make it 5 constraints. If you'd like to know just how relevant the project management triangle is, please attend my colleague's webinar on "Mastering the Triple Constraint" on Sept. 8th. You can register at https://www1.gotomeeting.com/register/959563376

terry.coburn
terry.coburn

Two many constraint categories can switch off your sponsors. I try to stick with the three mentioned and include things like Risk in the 'Scope' category using a definition of how risk aversive the project needs to be. Therefore, if we change time (and it's always changed to be sooner!) we can change scope by increasing the risk (e.g. less regression testing).

PMPsicle
PMPsicle

I doubt it. (Ignoring for the moment that the triple constraint has been 4 for a long time and is now 6+ - risk & resources being new with the phrase "but not limited to" weaseling itself in there). Your boss and your client are focused on three of the old triple constraints + one - scope, budget and schedule. Try blowing the budget or going over schedule or not delivering anything in the given time (all of which are possible with agile). You'll soon discover that they were expecting you to worry about quality, risk and resources -- as far as they were concerned that was fixed. (BTW, as a side comment, Agile and Waterfall as you refer to them are both PM techniques. They go into fashion, they fall out of fashion. Waterfall lifecycle is a way of describing the lifecycle of the project (or product or programming or anything else that goes through stages). Waterfall lifecycles are convenient descriptive models. They cannot become obsolete as a group since they only describe what is happening.) Agile is based on making a trade off (as is choosing Waterfall). High risk (mitigated but still there) vs fixed budget vs fixed scope. And change control is still part of the agile process. It's one of the ways your boss & client get insight & control on what you are doing. It's also why the flagship project for agile failed some 10 years after it was started. (It turned into a skunk works that never was implemented). Ultimately, agile and waterfall and ???? should not affect project management. You still need requirements, you still need change control, you still need project initiation and closeout and all the rest. What you are changing is how those functions are implemented (in some cases) and the level at which decisions are made. Agile uses scrums to manage the cycling of change control (1 per scrum). Waterfall, on the other hand, reacts as changes are identified. Unfortunately, decisions to allow the change often occur more slowly. If the decision to extend the scope/budget is refused then that scrum cycle doesn't occur. Instead the scrum starts over at the beginning. Try doing a scrum which is outside the scope of a fixed price contract. Or for that matter more scrums than have been budgeted for. One of your jobs as an agile project manager is to identify those changes which are going to have the effect of exceeding the total budget (both time & cost) or the scope. The decision to exceed the budget or change the scope is your sponsors' (i.e. boss & client). Trade-offs within the scope & budget are yours. (BTW this is true regardless of the choice of agile or waterfall -- it's part of project management and proper oversight. Your job as PM is to identify when you need to kick the decision upstairs.) Don't fall into the trap of Agile right/anything else wrong. Agile & Waterfall are simply two tools in your arsenal. It's up to you as PM to chose the one that is most appropriate to the task at hand. Project Management (ala PMBoK) are your specifications (i.e. what you have to do) not how you have to do it. Final comment, don't fall in love with the names ... Waterfall is actually more reactive than agile. Changes in waterfall are implemented as they are identified and decided on. The only schedule is that the executives who are the sponsors typically meet once per month. (I have seen them meet weekly however.) Agile on the other hand, schedules the change cycle (every three weeks for a two week scrum). So from that point of view agile is less agile than waterfall. Glen Ford, PMP http://www.TrainingNOW.ca http://www.LearningCreators.com/blog

ERICEV
ERICEV

I agree with your comments. However, triple constraints are no longer triple constraints according to PMI's PMBOK 4th ed. Triple constraints have been expanded to include quality, resource, and risk. These six constraints are now referred to as "Common project constraints". This does seem to cover your particular scenario.

gwcarter
gwcarter

Coding itself is outdated, having begun many years ago with Jacquard looms and Lady Ada Lovelace. A technique's age and even it's cometitors do not invalidate it. Having writtenthat, however, I must note that your telling poinis the inclusion of risk into the mix. Risk is the 800-pound gorilla in any proect,feature, or change order. Perhaps we could add it to the matrix and structure that matrix in an outline form by feature or element? Risk is non-negotiable and is a fundamental element in project masnagement, as is the ego and management style of the project sponsor.

QAonCall
QAonCall

A couple of things...3 or 6 is probably not the most important issue. All 6 should be considerations and probably are by the consultant (?) but rarely are by the client. They usually hire the consultant to accomplish something they 'can't'. This means the consultant has 'no limitations' in the client's eyes. This is the problem. How you deliver the message to the client that you do have limitations is the point (and of course that you DO!). While I agree all these things have influence, I would and do prefer to bring to the table the most applicable of the list. If a client is presented with 'too much' information it can cloud the decision and cause 'paralysis by analysis?. They hired you for your expertise, give it to them. If risk is low (from a technology and resource standpoint) why discuss it. Additionally, risk usually is the pivot in the triangle or quadrangle if you are CMM focused. Keep in mind that risk will be influenced by the decision to focus on the other three (4) so risk is a moving target. While I prefer the 'four corners' from CMM (Quality, Functionality, Cost, Schedule with risk as the pivot) they clearly are just 1 method of articulating the problem. I believe the authors point was to have the conversation. Managing the client relationship is key to success and rule #1 is still 'Communicate'. IMHO.

Editor's Picks