I attended a Certified ScrumMaster training class this year delivered by Lithespeed. The class was very valuable, and I want to share a tool, trade-off matrix, to help set customer and team expectations. In my opinion this is a tool that should be used on all projects early in the planning stage. Here is an example of a trade-off matrix.
|
Fixed |
Firm |
Flexible |
Target |
|
| Scope |
X |
All 30 Use Cases Identified |
||
| Time |
X |
3-6 months |
||
| Budget |
X |
$500k |
||
| Defects |
X |
2 Large Bugs per month is acceptable |
By documenting this at the beginning of a project, the project sponsor and all project stakeholders (including project team members) have a clear view of what project success looks like. In the example above success is implementing all features, within a budget close to $500k and somewhere within 3-6 months. In addition the sponsor is OK with 2 large bugs a month.
You may find that a project sponsor wants everything “Fixed.” By using this matrix to illustrate the triple constraint it helps drives your discussion explaining why there needs to be a trade-off.
I plan on using this to help define success. Please share any tools you use.
September 17th, 2007 at 5:17 pm
[…] Another One for the Toolbox […]
September 18th, 2007 at 3:03 am
Thanks for sharing. I presume there is some kind of method of prioritising, otherwise everything jut ends up being a fixed or firm tagret, right?
September 24th, 2007 at 2:31 pm
Great tool. We just delivered a major version for our Sales Force Automation system today and after the presentations I spent one hour discussing if it was a success or a partial success with my boss. From my point of view, when I've got the project, we were in a very hard situation, the relationship with the costumer (internal) was horrible after two very bad scoped versions (not by me!). All he wanted at that time was to deliver something good to the costumer as fast as possible and he accepted the risk of investing only part of the time needed to a good analysis before jumping to programming. Today, 3 months later we have an improved process and a better team assemblage and having a bad scope is not acceptable anymore, but he forgot how he felt at that time and is comparing the project results with his new expectation. If I had a matrix like this at that time, it would be easy for us to remember what success meant at the time we started the project. Thanks for the tool. Kerber - ITBA - Digitro technology www.digitro.com www.kerber.com.br
September 24th, 2007 at 9:52 pm
Claudio,
That’s it! I’m sorry you are not being rewarded for your efforts, but hopefully next time you can use this matrix to help everyone realize a great success. Keep it up!
March 18th, 2008 at 3:42 am
As a newly hired (inexperienced) BA I strongly believe that this is a tool to be used in my upcoming analysis tasks. Keep up with the informative work your are doing.
April 20th, 2008 at 12:03 pm
I’ve seen this illustration of the triple constraint used in some large scale projects we’ve worked on, without the last bit (which is defects). I personally feel, as a member of the IT department in general and a BA specifically, we should aim to make defect free solutions, therefore aiming to quantify the tolerance level of defects seems illogical to me. Without the defects part, this is a perfect tool and also a 3 by 3 matrix. I stress on the 3 by 3 part because EACH attribute (Scope, time and Budget), should have one and only one state (Fixed, Firm or Flexible). This encourages all participating stakeholders to think about which aspect of the project they are consciously willing to compromise.
April 21st, 2008 at 10:21 am
Thanks for yoiu comment Faizan. You can add or remove items as it pertains to your project. I used defects as an example.
I have to disagree slighly as it relates to defects. Although we should aim for defect free solutions, defects is an area where the team needs to understand tolerance. Different decisions can be made based on the tolerance for defects. If the time for the project is fixed and no tolerance for defects the team may need more resources than if there was some tolerance for defects.
I say keep defects in there even if it seems illogical!
April 22nd, 2008 at 9:39 am
Like the vulcans would say: “keep it, itīs illogical, but they are humans”.