Page 123 - DCAP304_DCAP515_SOFTWARE_PROJECT_MANAGEMENT
P. 123
Unit 6: Effort Estimation
they need in order to produce estimates; nevertheless, they need to come up with numbers. To Notes
deal with incomplete information, they must make assumptions about the work to be done. By
making assumptions, team members can leave placeholders for information that can be corrected
later, in order to make the estimate more accurate.
For the estimates to be most effective, the assumptions must be written down. Important
information is discovered during the discussion that the team will need to refer back to during
the development process, and if that information is not written down, the team will have to
have the discussion all over again. If an assumption turns out to be incorrect, the schedule will
need to be adjusted; they will be able to point to the exact cause of the delay by showing that a
documented assumption turned out to be incorrect. This will help the project manager explain
any resulting schedule delay to others in the organization and avoid that source of delays in the
future. The assumptions also provide a way to keep a record of team decisions, share those
decisions with others, and find errors in their decisions.
The team should hold a brainstorming session to try to identify as many assumptions as possible.
The bigger the list of assumptions, the lower the overall risk for the project. A project manager
may get better results from this session by helping the team see how these assumptions can
work to their benefit. Any software engineer who has had a bad experience with an estimate that
has turned out to be inaccurate will appreciate the value of assumptions: they serve as a warning
to the rest of the organization that the estimate is contingent on the assumptions being true. If
even one of these assumptions turns out to be incorrect, the team cannot be “blamed” for the
incorrect estimate that resulted.
While identifying assumptions is a skill that improves with experience, there are a set of questions
that can help a novice team member figure out what assumptions he or she needs to make in
order to properly estimate the software. The project manager can use these questions to help
lead the discussion to identify the assumptions:
Are there project goals that are known to the team but not written in any documentation?
Are there any concepts, terms, or definitions that need to be clarified?
Are there standards that must be met but will be expensive to comply with?
How will the development of this project differ from that of previous projects? Will there
be new tasks added that were not performed previously?
Are there technology and architecture decisions that have already been made?
What changes are likely to occur elsewhere in the organization that could cause this
estimate to be inaccurate?
Are there any issues that the team is known to disagree on that will affect the project?
The last bullet point is especially important. If one team member believes that the project will
go down one path while another team member believes the project will go down a different
path, the estimates could vary significantly, depending on which team member is correct. For
example, one team member may think that a certain off-the-shelf component should be used
because that is cheaper than building it, while another team member may believe that they must
build that component themselves because they cannot locate one for sale which suits their
particular needs. Instead of reaching an impasse, the team can make an assumption—either
assume that they will buy the component, or assume that they will build it—which will enable
them to move forward with the estimate. It should be easier to reach an agreement at this point
because it is not the final decision. By writing down the assumption, the team keeps a record of
the disagreement and leaves open the possibility that this will change in the future. The written
assumption will be especially useful later while doing a risk assessment for the project plan
because there is a risk that the assumption is incorrect.
LOVELY PROFESSIONAL UNIVERSITY 117