Re: There is no such thing as Technical Success
- --- In firstname.lastname@example.org, David A Barrett
> I think that Scrum blurs the definition of "success". Atraditional PM
> definition of success might be, "Completion: On time, on budget, onscope".
Agree. Traditional software development defined success based on the
triple contraint you described as it was measured at project
An alternative is a balanced scorecard approach. Balanced scorecards
are often used to guage organizational performance but typically not
not defined / measured at a project level.
A project's success would be measured in different perspectives.
Another key point is that you measure thoughout the project (to make
the necessary portfolio decisions), and you do not stop measuring at
the completion of the project. As financial, customer satisfaction,
and quality measures may not be known till months after the completion
of the project.
Here are the typical perspectives using a goal/measure approach.
1) Shareholder perspective -- (eg. cash flow, quarterly sales, market
2) Customer perspective (eg. on time delivery as defined by the
customer, customer partnership measures, customer satis.)
3) Internal business perspective. This involves among other things
the triple constraint you mentioned (on time, on budget, on scope), as
well as quality, engineering efficiency metrics)
4) Innovative and Learning Perspective. Perhaps this is what you are
referring to as "technical success" (eg. did we improve our
technological skill/ processes to deliver the next project
So, I disagree there is no such thing as technical success. All of
these perspectives collectively provide project value.
I think Scrum does a good job in a more strategic view of project
success by focusing success on business value.
How we measure project success and how well these measures are aligned
to overall company strategy is the Enterprise Agile concepts that have
been discusssed here. A balanced scorecard is a good tool to do this.