 |
 |
 |
 |
406.0 Determine Project Size and Lifecycle Model
The LifecycleStep process should be customized and scaled based on the size of the project.
-
Larger projects may require most of the steps and activities specified in this methodology. A formal methodology provides the most value on larger projects, since they need more structure and discipline.
-
Smaller projects may not need much in terms of formal methodologies at all. Smaller projects can be categorized as Work Requests, tasks, or bug fixes. These could still be required to utilize portions of the system methodology that add value, but there is a minimum requirement to update the Service Ticket documentation as necessary.
-
Medium projects need some level of structure in the middle. They need more methodology than the smaller projects but less than the larger projects. The project manager should use judgment and discretion to determine which activities to execute based on the requirements of the organization and the needs of the project.
Project Size
The scalability of the methodology is primarily based on the size of the project. There are many factors that can be taken into account, but there are three that are the most important. The first is the estimated effort of the project. The general guidelines utilized by the TenStep process are as follows:
|
Size |
Effort Hours |
|
Small |
1-250 hours |
|
Medium |
251 – 5000 hours |
|
Large |
over 5000 hours |
In your company, the effort hours for categorizing projects may be different. However, in general, the larger the project, the more structure and formality you want in the project management process.
The second factor is the experience level of the project manager. If the project manager is very experienced, you might allow him or her to manage larger projects with less rigor, or at least up to a higher effort threshold. On the other hand, you may ask an inexperienced project manager to manage a 2000 hour project as if it was a large one, since they may need more structure.
The third factor is the complexity and business criticality of the project. For example, you may want to manage a 1000 hour project as if it were large if the project is extremely critical to the business. Or, you may want to manage a 500 hour project as a small one because you have managed two similar projects before, and therefore it seems to be low risk.
Type of Lifecycle
There are many ways to execute a project. Although classic waterfall (Analysis, Design, Construct, Test and Implement) can be used on all projects, it is not always the best model for all projects. Depending on the characteristics of the project, other lifecycle models may be more effective. The following descriptions will help provide some guidance on the best fit for the lifecycle model and templates to use for the project.
-
Iterative. This is a specific model for custom software development. The project must be somewhat complicated in that it will take multiple cycles to completely develop the application. If the application seems simple and the requirements seem relatively straightforward, the Waterfall model may be better.
-
Package / Vendor Selection & Implementation. This model is specifically used if your project requires you to evaluate packages or vendors. There are times when a package or vendor selection is a part of a larger project. In that case the package / vendor selection activities would be added to another schedule model.
-
Waterfall. This is the default lifecycle for all projects, unless it is determined that another of the specialty models is more appropriate. This model includes upfront analysis, then the sequential design, construct, test and implementation processes.
-
Enhancements. This model is used when you are modifying an existing solution. It assumes that many of the design decisions are already made since the new work needs to integrate into a solution that already exists. If the enhancement is very large, it is possible that the iterative development model could be used. Otherwise, enhancements are typically done with a Waterfall model.
-
Releases. This model is used when you are batching together a number of changes into one release package. This is usually the case when you have a number of enhancements. The Release model allows you to select a specific set of enhancements to implement, work on all of them at once, and then implement the entire set of enhancements all at once. See 496.3 Schedule Library for a Software Release Schedule.
-
Research and Development. This model is used when you are performing research on some type of solution. The analysis consists of determining your requirements and seeing how you can satisfy the requirements. The project may end after the research is completed, or else you can proceed to a development phase. The development phase is used to create a short-term solution that simply determines if the solution is viable. The activities are streamlined since the solution will be thrown away after the final proposal is made. See 496.3 Schedule Library for a Research and Development Schedule.
[ Previous Page - 405.0 LifecycleStep Principles] [ Next Page - 407.0 Project Roles and Responsibilities]
