Overview |  | Roles |  | Work Items |  | Views |  | CMMI |  | Index |  | Glossary |

Project Portal
| ### Next Steps Review Project Plan |
| Define Budget and Schedule ( 2 : PP : 2 : 2.1 ) ( 3 : IPM : 1 : 1.2 ) Business Analyst
Activity: Define Budget and Schedule
Business Analyst
|  |  |  | Planning |  |
|  | Participating Roles Responsible: Business Analyst Accountable: Project Manager Consult: Any Informed: All
### Overview At the beginning of a project there is still a lot of uncertainty. However, to facilitate corporate governance there is a need to present a budget and schedule. It is likely that both the budget and schedule are approximations; however a best effort should be made to determine a budget and schedule which are congruent with the business case for the product of the project. # Entry Criteria Business Case The business case justifies the start of a project to investigate creating the product. Vision Statement The vision for the product. Scenarios Detailed end-to-end storyboards describing usage of the envisioned product by one or more personas. Personas Caricatures of real users identifying target market segments or demographics. Lifestyle Snapshots Stories of a day in the life of a persona, identifying opportunities of the new product to be used. Existing Architecture Any existing product or enterprise architecture. # Sub-Activities
1 | Determine Whether Date or Scope Driven | Most projects ought to be date driven. However, a few need to be scope driven because delivery date is less important than delivering the full functionality. In most other cases, the business case will call for a product to materialize during a window of market opportunity. Perhaps there is a goal to be first to market. In most cases, date matters more. If you are being asked to estimate a date based on functionality, challenge it with the sponsor. Does the project really need to be functionality driven, or does the sponsor really need delivery before or on a given date?
2 | Define Delivery Date | If the business case calls for delivery in a given market window, then agree to a delivery date which makes most sense to realize the vision of the product and the financial returns detailed in the business case. Otherwise, defer the delivery date until more detailed planning can be done.
3 | Define High Level Dependencies | Using the vision statement, personas, outlined end-to-end scenarios and any storyboards or lifestyle snapshots, or any existing architecture or prototypes, determine high level dependencies for scheduling more detailed requirements which will follow as the project and its iterations progress.
4 | Divide Schedule into Iterations | Based on the business case, domain, identified dependencies, and proposed team organization, divide the schedule into iterations. Set the iteration cadence based on the organization and business. There is a transaction cost to iterations that must be weighed against the benefit of feedback and focus that a short delivery date gives to the team. Iterations should typically be between two and six weeks though up to three months may be appropriate in some domains. Longer than three months is inappropriate. Even the largest of businesses report progress and financial data quarterly.
5 | Divide Functionality Across Iterations | Based on the identified dependencies and an analysis of the domain, business case, and feedback from the sponsor, divide the loosely defined end-to-end scenarios and personas across the iterations. This provides a rough guide to what will be delivered and when.
6 | Determine Budget | A budget should primarily be based on the business case; that is, how much is the business willing to invest in developing the product. The suggested costs of running the project should be secondary. The budget should not be calculated by the costs of the project staff, facilities, and equipment multiplied by the length of the project. Rather, the budget for staffing, facilities, and equipment should be derived out of what the business case can afford. In the event that the anticipated costs are significantly smaller than the affordable budget, perhaps it is acceptable to reduce the budget. However, a budget should maintain a buffer for contingencies. Hence, reducing budget should not be done before risk analysis is conducted. Equally, a budget may need to change based on risk analysis.
# Exit Criteria
| First draft of approximate budget.
| First draft of project schedule.
© 2005 Microsoft Corporation. All rights reserved. MSF for CMMI Process Improvement: 1.00.0000.00 |