 |
 |
 |
 |
402.0 Assumptions
This page describes some assumptions that were made that will put the LifecycleStep process into better perspective.
-
The methodology is written with the project manager and project team as the intended audience. In many cases, the names 'project manager', 'analyst', 'designer', etc are specifically mentioned. In other cases, the content may say 'you' or 'your'. The assumption is that 'you' (the reader) are the project manager or a team member.
-
A set of generics roles is defined in LifecycleStep including "project manager", "analyst", "designer", etc. However, the exact title and roles in your company may well be different.
-
LifecycleStep refers to specialist roles in many section of the process. For instance, different sections refer to the role of "analyst", "designer", "programmer", "test team", etc. However, these roles do not imply that different people are necessarily involved. On many projects, for instance, the roles of analyst and designer are performed by the same people. In fact, the same group of core people may well be involved throughout the lifecycle, each of whom is performing all of the project roles as the project progresses.
-
LifecycleStep refers to the deliverables of the project with the generic name of "solution." That is, all projects exist to create a solution. Depending on the project, the actual deliverables could be hardware, software, a bridge, marketing campaign, etc. However, LifecycleStep refers to all of these with the generic name of "solution".
-
LifecycleStep refers to the people that request the project as "clients". In some companies, these people have different names such as "customers" or "the public". However, LifecycleStep generically refers to this role as a client. When LifecycleStep does refer to "customers" the context is external customers in the marketplace, not internal "clients" within your own company.
-
LifecycleStep refers to "business requirements" and "requirements" depending on the term that seems to make most sense. For all practical purposes the two terms are synonymous. While not all requirements are "business" focused, all projects are typically done to provide value to the business and therefore the requirements are all business related. Some methodologies also refer to technical requirements, but in LifecycleStep the technical requirements would all be a part of the design and architecture of the solution.
-
LifecycleStep was written to be able to support large projects and needs to be comprehensive to ensure that large projects can be successful. However, this means that smaller projects may not need all of the steps associated with LifecycleStep. Each project team must use the content of LifecycleStep as a starting point and customize the activities as needed. This includes adding important activities that are needed by your project and deleting activities in LifecycleStep that are not needed for your project.
-
There are many models in the marketplace for defining the project lifecycle. The models within LifecycleStep reflect the experience and best practices of the author.
-
There are two main components on every project - the project management process and the actual project lifecycle. The LifecycleStep Process goes hand-in-hand with the TenStep Project Management Process® (www.TenStep.com). For example, gathering business requirements is considered a part of the project management process in some methodologies. However, it is not considered a part of the TenStep process and it is considered a party of the LifecycleStep process. Likewise, some lifecycle methodologies have activities for quality control and risk management. These are important concepts, but they are considered a project management function and are therefore a part of the TenStep Project Management Process. Therefore, they are no considered a part of LifecycleStep.
-
LifecycleStep is designed to be comprehensive, yet not overly burdensome for any project. The process is flexible and scalable. LifecycleStep defines the overall framework for larger projects. Smaller projects may not need to execute all of the steps that are defined. For instance, section 414.0 Defining Project Strategies would not be needed for small to medium sized projects. Likewise, all of the activities associated with training can be bypassed if the project will not require any training element.
[ Previous Page - 401.0 The Value of Project Lifecycle Methodology] [ Next Page - 403.0 LifecycleStep Caveats]
