MBAFI 5216 - Project Management - Note 07 - Note
MBAFI 5216 - Project Management - Note 07 - Note
MBAFI 5216 - Project Management - Note 07 - Note
Management
MBA 5216 - Project Management
Note 07
Presented By: Ranga Gamage, PMP, MBA, BSc., CIMA
Virtual Teams
• Basecamp
• Buffer
• Zapier
• Automattic
• Trello
The above stories are all related, and could all be considered individual tasks
that drive toward the completion of a larger body of work (an epic). In this case,
the epic might be “Improve Streaming Service for Q1 Launch.”
1. We deconstruct the software system along functional boundaries. This is simply functional
decomposition of the system, and the result is often a requirements document. We often have a
different understanding to that of the customer, so requirements documents are often a ‘best first
guess’ of what the system needs.
3. Some contingency factor is then applied. This contingency factor goes by various names such as
‘transactional complexity’, or ‘risk assessment factor’ and are gross multipliers often by up to +/- 150%.
• Any changes to the initial requirements as a separate project even though the we know that the
initial requirements are incorrect by 40%-60%.
• In an even more egregious example, software might be released on time to the client, but with
known defects (i.e., the quality of the product is compromised to meet the time, cost and scope
parameters).
• The true cost of producing software is hidden by shifting work between different cost
centers, or by re-defining what’s ‘in scope’ [also know as finessing scope]. It’s an
accepted way for suppliers and customers to lie to each other.
• We would then assign a dollar range to each size on our scale; XS would be
$10,000-$20,000, S would be $40,000-$80, 000, M would be $150,000-$200,000,
etc. We would tally up the final figure to give an upper and lower bound for the
total cost.
• If the customer wanted a fixed price project, then we would quote the upper
bound figure to compensate us for the additional risk that this might incur. If
they’re willing to work on a more flexible basis (say fixed-cost, variable-scope),
then we could consider a quoting a lower cost.
09/06/2023 MBA 5216 - Project Management - Note 07 44
Cost Management with Traditional Cost Management with Agile Approaches
Approaches
Cost, like time, is based on fixed scope. Project schedule, not scope, has the biggest effect on cost. You can start with
a fixed cost and a fixed amount of time, and then complete requirements as
potentially shippable functionality that fit into your budget and schedule.
Organizations estimate project costs and Product owners often secure project funding after the product roadmap stage
fund projects before the project starts. is complete. Some organizations even fund agile projects one release at a
time; product owners will secure funding after completing release planning
for each release.
New requirements mean higher costs. Project teams can replace lower-priority requirements with new, equivalently
Because project managers estimate costs sized high-priority requirements with no effect on time or cost.
based on what they know at the project
start, which is very little, cost overruns are
common.
Scope bloat wastes large amounts of money Because agile development teams complete requirements by priority, they
on features that people simply do not use. concentrate on creating only the product features that users need, whether
those features are added on day 1 or day 100 of the project.
Projects cannot generate revenue until the Project teams can release working, revenue-generating functionality early,
project is complete. creating a self-funding project.
• Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2,
3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values
represent the number of story points, ideal days, or other units in which the
team estimates.
09/06/2023 MBA 5216 - Project Management - Note 07 46
Effort Estimations in Agile Projects
• Planning Poker
• The estimators discuss the feature, asking questions of the product owner as needed.
When the feature has been fully discussed, each estimator privately selects one card to
represent his or her estimate. All cards are then revealed at the same time.
• If all estimators selected the same value, that becomes the estimate. If not, the
estimators discuss their estimates. The high and low estimators should especially share
their reasons. After further discussion, each estimator reselects an estimate card, and all
cards are again revealed at the same time.
• The poker planning process is repeated until consensus is achieved or until the
estimators decide that agile estimating and planning of a particular item needs to be
deferred until additional information can be acquired.
09/06/2023 MBA 5216 - Project Management - Note 07 47
Effort Estimations in Agile Projects
• Affinity Grouping
• An even faster way to estimate, and one used when
the number of items to estimate is large, is affinity
grouping. Team members simply group items
together that are like-sized. The method is simple
and fast:
• The first item is read to the team members and placed on
the wall.
• The second item is read, and the team is asked if it is
smaller or larger than the first item; placement on the wall
corresponds to the team's response (larger is to the right,
smaller is to the left).
• The third item is read, and the team is asked if it is smaller
or larger than the first and/or second items; the item is
placed on the wall accordingly.
• Control is then turned over to the team to finish the affinity
grouping for the remainder of the items.