Renaissance Information
Systems, Inc. has been using something we call Feature Cards for project
estimation and management for a few years and have found this approach to be a
valuable tool in managing the project scope and ultimately cost.
All of the functional
business requirements for a project are broken into individual features and a
Feature Card is created for each. While there are cases where some features are
dependent upon one or more others, the goal is to provide individual requirements
that can be prioritized for implementation at the customer’s discretion. Each
Feature Card is presented on a half-sheet of paper. This allows the customer to
evaluate each feature individually. We often recommend that three or more piles
be created when prioritizing the features and the half-sheets facilitate this
process.
Projects managed in
this manner are implemented in multiple phases. The features with the highest
priority and those that are required for the application’s foundation are
grouped together for the initial phase. At the end of each phase, the features
implemented result in a limited but useful functioning system. By implementing the features
with the highest priority first, the greatest benefit is achieved at the
beginning of the project. Further enhancements to the core functionality are
then added as the project progresses.
At the end of each
phase, that status of the project is reviewed. The remaining feature cards are
re-prioritized often with new features being added and others removed. The highest priority
features from the remaining cards are used to drive the next implementation
phase. This process continues until the project reaches maturity or budget
constraints prevent further development. If a project is stopped for budgetary
reasons, a functioning solution is still in place that can be augmented
at a later date.
An estimate summary
accompanies the feature cards to show the total project cost should
all features be implemented. When assigning a time estimate to each
feature, we evaluate how well we understand both the business requirements and
how the solution will be implemented. If we believe we have a solid
understanding of both those facets, then we have a high level of confidence in
our estimate. Experience shows that actual development time generally varies by
no more than 20% of the estimate.
If we are unclear on either the business requirements or their implementation method, then we are
only moderately confident in the estimate. Features with moderately confident
estimates are given a 40% variance. If we are unclear on both areas, then the
estimate is given a low confidence level. If a feature’s estimate has a low
confidence level we recommend that more time be spent on analysis and design so
that a better estimate can be given, but it is sometimes helpful to get that
"ballpark" estimate up front to help gauge the feature’s priority and
viability.