Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
OpenAgile System versus Conventional Project Management
Transcript of OpenAgile System versus Conventional Project Management
Conventional Project Management
A "Scope of Work" is defined during a planning phase. Often referred to as:
A "Cost Analysis" is performed in the planning phase based on the given scope of work and an assumed timeline: such as the fiscal year, within a company's "5-year plan".
This occurs when the requirements change during the implementation. As the client begins to see real product, they often want to make changes.
This occurs when important, high-priority requirements haven't been implemented before the project's closing date.
The "Timeline" is usually variable. This can be adjusted by either increasing/decreasing the scope of work or by increasing/decreasing the budget.
macro and micro are
executed in a sequence
which is arranged according to
their presumed dependencies. This
leads to the creation of an "Event Chain"
- often presented as a Gantt chart - which looks like a waterfall.
This occurs due to Scope Creep or if the cost of goods and services change after the planning phase - often due to inflation or unpredictable market conditions.
Waste by-products and missed opportunities are ignored.
revising the plan and "learning along the way" are not built into this methodolody. An assumption is made that "while planning, we made sure to make the best possible use of resources - therefore waste isn't possible."
This occurs when essential requirements are not complete by the proposed closing date of the project.
Again, eliminating waste is considered impossible. The assumption is always that all processes and resources are already optimized. (And if they're not, then fixing them is not within the scope of 'this' project - we'll have to fix them afterwards.)
Problems, when they occur, are considered failures. They are attributed to a failure to plan or manage effectively.
"If only we had planned better..." This leads to more emphasis on planning in all subsequent projects.
"If only we could manage our resources, budget, assets, time, information, change, conflict, crisis, process, risk, systems, strategy, quality, logistics, design, customer relations, supply chain better." This leads to greater expectations on administrative personel and a greater emphasis on "due process" and "best practices".
Agile: Delivered Value
Waterfall: Delivered Value
Agile: Constant Team Cost
"Scope of Work"
Cannot occur. The team commits to delivering only the most valueable tasks in the most immediate work cycle. Hence, the scope of work is determined by the team's capacity.
Should not occur. Every cycle is focused towards delivering value. If software, then this may be a "potentially useable product"; if music recording, then this may be a "potentially sellable product".
Cannot occur. Work cycles are determined to be only as long as the team can avoid breaking changes. If the cost of goods and services may change within two weeks, then the work cycle must be less than two weeks. Hence, the scope can be accurately adjusted - frequently - according to current market conditions.
Can be eliminated. Revising the plan and "learning along the way" are built into this methodolody. If resources are wasted during a work cycle, then the team can determine better ways to utilize those resources in each subsequent cycle. If an new opportunity presents itself - for example, if new products are released or new methods are found which make the team's work more efficient - the team can quickly integrate and take advantage of new opportunities.
Not necessary. The team must only commit to the next work cycle; even if the client chooses to end the engagement early, the team will have already delivered the most valueable task items by implementing the most valueable requirements.
Problems, when they occur, are considered learning opportunities. They are attributed to the team's courageous ability to take new action.
Systematic application of the Learning Circle ensures that the team learns from their errors.
There's no such thing as "best practice" - only "better" practices.
Common Problems: Avoided
Agile Project Management
We usually know the cost in advance of a project.
A customer may indicate they want to spend less then $x.
A competitor may charge $n for comparable product.
We usually know the time in advance of a project.
We may know the sprint length of an agile team.
A client may indicate they want a finished product by a specific date.
A competitor may be capable of completing a comparable product in a predictable amount of time.
Agile systems make the more pragramitic assumption that we can neither control nor predetermine total time nor cost; hence, "Scope" is the variable. Our capacity to deliver value within a fixed time and budget is the only factor we may influence.
the act of assisting an individual, team, or organization to reach a destination by accompanying, giving directions, or supplying advice.
We search for the principles involved in our work.
systematically create a plan of action
Carry out the plans we have created.
We do our work.
and the act of learning.
Love for the Work
gather observations about what we have done
to plunge into the unknown.
from preconceived notions.
for the underlying principles
All work is performed in short, iterative cycles.
Planning, Action, Reflection, and Learning occur frequently throughout the team's operation.
Tasks are executed in order of their "value" - which is measured against the team's "goal".
New & Improved Features!
New & Improved Features!
This Prezi by David Sabine (http://tumblr.davesabine.com) is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at http://wiki.openagile.org/