| HOME Software Testing Data Mining and Warehousing |
|
A new project begins when it’s identified as a bona fide opportunity within the performing organization. For purposes of this methodology, an opportunity can be named as a project at the onset of the project initiation process and then simply be discontinued (i.e., terminated) if it doesn’t subsequently gain required internal or external customer selection and approval. In a sense, Project Initiation is a series of pre-selection practices that recognizes a potential work opportunity, aligns it with a specific customer (either internal or external), and defines it in terms of the project management effort to be pursued. All opportunities are required to undergo a more or less formal internal project selection process. Some selected projects must also undergo an external customer's acquisition and selection process that involves proposal preparation and a formal bidding process. These project initiation practices, in conjunction with project selection practices, will assist the project manager (or other designated project "initiation" manager) in preparing the opportunity for either of those encounters. To that end, Customer Identification and Opportunity Identification practices are applied. As more information about the customer and the opportunity becomes known and evaluated, the necessary indications will emerge regarding whether the opportunity warrants internal selection and external pursuit of the customer's work. Also, the information compiled by project initiation practices will often prove invaluable to communication and collaboration activities that are conducted throughout the subsequent Plan and Perform Phases. This practice area is highlighted by the need to define the project-that is, specify its objectives and scope, nature of work, preliminary estimates, and several other details that enable the project effort to be envisioned before it begins, and before time, resources, and costs are allocated. Project Definition Development provides an overview of the project to help managers deliberate project selection within the organization. In turn, Project Classification Development is sort of an extension of the project definition; it describes the project against an established classification scheme that prompts recognition of the project size, type, complexity, etc., with out having to describe all characteristics in detail to all concerned project stakeholders. Ideally, the project manager, the project management office (PMO), or some other representative of the project management environment is involved at the project initiation stage. However, it’s not uncommon for this practice area to be largely associated with business development, particularly in organizations where projects represent revenue-generating opportunities that are uncovered in the marketplace. In the context of project management, project initiation practices are necessary steps that will facilitate the transition of an opportunity into a project. Project Initiation precedes actual Project Selection (a separate practice area), but the information and output of project initiation distinctly contributes to project selection. There are four primary practices associated with Project Initiation: Customer Identification; Opportunity Identification; Project Definition Development; Project Classification Development; Methodology users should note that, while these prescribed practices specify primary activities and steps for initiating a project, other project management practice areas could also con tribute in some degree to the accomplishment of project initiation, as may be determined within a particular organization. IDENTIFICATION of CUSTOMER The customer is the person or organization for whom the project is being undertaken. This could be an internal customer in the business environment or an external customer in the marketplace. In either case, knowing about the customer and the customer's business interests is a prerequisite to project success. The project manager should examine sufficient customer information during project initiation to ensure that any pro posed business and technical solution will be appropriate to the customer's organization. Many of the more common customer information elements are associated with technical needs, but good project management suggests that other information related to the customer's business is valuable as well. This practice discusses customer information that can be compiled to assist not only in learning about the customer for project initiation purposes but also in managing the ongoing customer relationship during the project. Conceptually ... This practice provides the project manager, the project team, the business development manager, and the organization with relevant information about each project customer. The underlying purpose of this practice is quite simple: know the customer! Know who the customer is, know what the customer wants, and know who represents the customer's interests in business transactions. In knowing the customer, the project manager will gain insight into the customer's business interests and sensitivities. Also, the project manager will identify the personalities within the customer environment that will influence matters such as contract award, customer participation, deliverable acceptance, deliverable payments, and the general demeanor of key and prominent customer representatives. Customer Identification is normally conducted in the Profile Phase in association with project initiation, but it can be accomplished or updated at any time during the project. Customer Contact Information Every project has a customer. Therefore, there is at least one primary customer point of contact for every project. That per son needs to be identified as a means of establishing the necessary communication with the customer. On smaller projects, that individual will be the source of and will control customer information; he or she may even represent the sole interested stakeholder in the customer's business environment. On larger, more complex projects, there could be multiple customer points of contact that need to be identified for their roles and responsibilities in coordinating and collaborating with the project manager on relevant project and business information. Therefore, it’s sometimes necessary to look for at least two prominent customer points of contact for larger projects-the customer's business manager and the customer's technical manager, as discussed in the following text. Customer Business Manager This individual in the customer's business environment will usually hold responsibility for and interest in areas of contract administration and compliance-managing issued contracts and associated extensions or amendments, managing invoices and payments, and overseeing acceptance of project deliverables specified by the contract. This role is not necessarily the customer's "contracting officer" who would prepare, negotiate, and sign any relevant contract for project work; but this person could fill that role. The business manager could also have interest in monitoring project staff strength, qualification, and availability. Also, this role could hold responsibility for project fund distribution, including review and approval of any expenses incurred and reported by project staff members, and analysis of overall expenditure trends. Customer Technical Manager This individual in the customer's business environment will usually hold responsibility for and interest in areas of technical performance and technical deliverable development. This person often serves as the point of contact for the specification of technical needs and requirements, and sometimes conducts or participates in technical feasibility studies and analyses, technical design and plan reviews, and deliverable testing and acceptance activities. On occasions when the customer fields a project team, this individual could serve as the customer's project manager. The customer is the most prominent external stakeholder in the project management environment, and arguably the most important. Therefore, it’s essential that appropriate points of contact with the customer be established early in the project so as to facilitate two-way communication with the project manager and the performing organization. This can be facilitated by preparing a directory of customer points of contact. Also, customer points of contact should as well be considered for inclusion in any stakeholder analysis that is conducted as a means to discern and manage their participation in and influence on project performance. Customer Business Information The project manager or other responsible manager (e.g., business development manager) in the performing organization should acquire and manage customer business information as a means to becoming more effective in customer communication and collaboration, fulfilling business needs (associated with project execution), and understanding the current status of the customer relationship. This includes three types of customer business information: Customer Business Profile ---The customer's business profile contains any relevant information the performing organization deems necessary to gain an adequate understanding of the nature of the customer's business. Fundamental information elements in the customer business profile can include:
Customer Relationship History -- Information on customer relationship history should be kept on record in order to examine past business dealings with the customer. Its focus is on being able to review past business with the customer, but it can also look at the customer's other dealings in the industry and in the marketplace. Fundamental information elements in the customer relationship history package can include:
Customer Business Approach--Information about the customer's business approach may well be included in the customer relationship history but is separated here to distinguish the nature of information compiled. The primary information elements collected can sometimes be based on the discernment and judgment of managers in the performing organization in contrast to absolute factual data. This information helps to examine the customer and associated opportunities from a business interest perspective of the organization. Fundamental information elements in the customer business approach package can include management perspectives on:
These perspectives can be developed by the project manager on smaller projects. Larger, high-value projects may require polling additional internal project stakeholders, to include the project executive/sponsor, the business development manager, and the PMO manager. These three areas of customer business information can be comprehensive or basic according to established business needs and the capacity to manage a formal customer identification process. To the extent that a project knowledge management system is established, that system would be a primary means for introducing customer information for use by the PMO, by project managers, and by others in the project management environment. IDENTIFICATION of OPPORTUNITY In conjunction with compiling customer business information, the project manager will also have to learn about the customer's unique needs, requirements, and expectations for the pending project. This will allow the project manager, business development managers, and any other participating managers in the performing organization to develop the preliminary business and technical solutions that will help achieve the customer's desired objectives. The opportunity is specified with sufficient detail to enable the project manager to gain an understanding of the project work that needs to be accomplished. In turn, this "specification" is used to collaborate and confirm an accurate understanding with the customer and to further convey that understanding to additional project team members who will participate in business and technical solution development, proposal preparation, and project planning. Conceptually ... This practice provides the project manager, the project team, the business development manager, and the organization with relevant information about what the customer needs and what the customer wants. The purpose of this practice is to ensure that the project opportunity has been specified in some way and examined to some reasonable extent in order to ascertain the customer's perspective of the needs, requirements, and desired outcomes of the pending project. Furthermore, the project opportunity is analyzed to determine the customer's readiness to pursue the project, the customer's intended means of selecting the performing organization (and likelihood of selection), and the availability of project funding at the onset of the project. Upon completion of opportunity identification, the performing organization should have a preliminary indication of whether or not to pursue the project based on an examination of customer need and interest indicators. Opportunity Identification is always done in the Profile Phase during project initiation. It would be unlikely to revisit this activity once the project has started. However, on rare occasions, new information may surface, the customer's needs and requirements may be modified, or the customer's perspective on spending may change to warrant revisiting opportunity identification. Initial Project Requirements and Specifications Review Requirements and specifications represent the customer's perspective of what needs to be achieved by the project, and these items should be collected and reviewed as a part of opportunity identification. In some cases, it may be necessary for the project manager, project team, or business development manager to assist the customer in preparing this information. If so, it’s important that such information always reflect the customer's interests and point of view of what is to be achieved. A few sample information elements collected and used in opportunity identification include:
Technical Design Document Project requirements and specifications documents are used and examined more closely at the onset of project planning (see Project Requirements Examination under the Project Planning practice area for additional guidance on establishing and managing project requirements). Customer Readiness Assessment Whether the opportunity is a competitive one in the market place or one in response to an internal request or mandate, it’s still necessary to consider the customer's perspective on "offering" the opportunity. A customer readiness assessment allows the pre-project customer relationship to be examined, if only briefly. In turn, it also gives the performing organization preliminary insight about whether or not to pursue the opportunity. The assessment can be an exhaustive, numerical-based calculation or a simple review of factors that will contribute to the customer's decision for awarding the project to the performing organization. The performing organization, in turn, should consider the following indicators:
These items should provide insight into the pre-project relationship with the customer and an indication of the potential to win the opportunity. For an internal, noncompetitive customer opportunity, it can provide an indication of the nature of the interaction to be expected during project planning and execution. Customer Opportunity Analysis The initial examination of opportunity documentation, combined with any direct contact and communication with the customer, provides the information needed for the opportunity analysis. This considers not only the requirements for the project but also the requirements for obtaining the project. The most common method for obtaining a project in the marketplace is through the submittal of technical and business proposals to the prospective customer. This is prevalent in a competitive marketplace. However, even when the opportunity is an internal, noncompetitive one, it’s still good practice to prepare and submit a proposal to the end customer to identify the technical approach (e.g., work plan) and any associated funding requirements that may be incurred through cross-department accounting methods. The opportunity analysis considers the following information:
This information will help the project manager to conduct further project initiation activities, proposal development and management activities, and subsequent project planning activities. PROJECT DEFINITION DEVELOPMENT Each business opportunity or internal mandate is examined in sufficient detail to ascertain if it’s within the current capabilities and business interests of the performing organization to conduct such a project. The project definition is a primary contributor to that determination because it provides the first preliminary description of the project from both business and project management perspectives. In a sense, albeit somewhat abbreviated, it’s the essence of the first "project plan" that is developed, and it’s subsequently used to guide the more detailed project planning that is conducted following project selection. Project definition development is a critical prerequisite to project work plan development. In some organizations, project definition is sometimes considered a part of the Project Charter Development effort. While it’s treated separately within this methodology, project definition can be easily integrated along with other Profile Phase materials into a project charter package, as may be desired within the organization. Conceptually ... This practice provides the project manager, the project team, and the organization with relevant information about the project so as to distinguish it from other projects and to place logical and rational boundaries on the work to be performed. The purpose of this practice is to specify known-to-date customer requirements in project management terms-project objectives, project scope, a preliminary list of project deliverables, and any project assumptions and constraints. Most project definition documents also include initial estimates of cost, schedule, and resource utilization requirements, and this is included in the following discussion. However, in this methodology, project estimating is treated separately (see the project estimating practice area), but those estimating practices can be used to prepare initial estimates in conjunction with project definition development. Upon completing the project definition, the project manager and the performing organization should have a reasonable understanding of what the project will entail in terms of cost, schedule, and resource utilization. The project manager should be the lead developer of project definition. Project Definition: Development is always performed in the Profile Phase during project initiation. It’s used again in conjunction with project selection activities, and during project planning, when it serves as the basis for many project planning documents. Project definition should be used and maintained as a project management tool throughout the duration of the project. Project Objectives The project's objectives may already be stated in customer requirements documents, or they may have to be developed by the project manager and project team based on a general understanding of the customer's requirements. If not otherwise provided by the customer, project objectives that are developed need to be reviewed and confirmed by the customer. Simply stated, project objectives are those matters that need to be achieved as a result of project performance. They are the reason the project is being conducted. The project is successful when its primary objectives are achieved. Therefore, all project management plans, decisions, and work efforts should be aligned with and directed toward achievement of project objectives. Conversely, if an action or work effort on the project does not contribute to achieving specified objectives, then doing that work is a misdirection of valuable time and effort and should not be included in the planned project effort. This necessitates that project objectives are clear, concise, and reasonable to pursue. The concept of "SMART" objectives" is often used in preparing project objectives. This process is recommended, and the term SMART is: Specific-- Project objectives need to have specific rather than broad statements of what is to be accomplished. Specific can also mean unambiguous to the extent that all project stakeholders should have a similar under standing of the objectives. Measurable--Project objectives need to be measured in order to know when they have been achieved. It’s not uncommon for such measurements to be numerical, but they can also be of binary nature, e.g., true/false, yes/no, or on/off. They can likewise be related to thresholds, e.g., monetary value ($), time values (hours), and volume (work effort/hour), and the achievement of such thresholds as completion of project deliverables. Agreed-to--Project objectives ultimately become man dates for the project, and therefore it’s necessary to achieve reasonable consensus when developing them. Inasmuch as they will guide all subsequent project and project management activities, key project stakeholders need to share their buy-in or agreement with stated project objectives. Realistic -- Project objectives need to have a rational basis and a reasonable opportunity for success. So, project objectives shouldn’t aim for unreasonable time constraints, unreasonable work efforts that cannot be completed with the anticipated project staffing, or results that have not been achieved before because of technology limitations. Time-based -- Project objectives need to guide the project's time frame, which will have a discernable finish point. Therefore, the stated objectives should reflect the time-based conditions in which they will be completed or otherwise achieved. When project objectives need to be developed, this is normally a team-based activity. Ideally, the customer is a participating member of this team. However, sometimes project objectives can be prepared by a qualified individual for sub sequent project manager, project team, executive sponsor, and customer review and acceptance. It’s better to have fewer objectives than more objectives, and three to five objectives for a project are usually manage able. You should rarely have more than seven stated project objectives, and if such a need does occur, that may signal a need to reconsider two or more separate projects in lieu of the original project. Project objectives need to be precise, as indicated by the SMART objectives process described earlier. They will be aligned with and used (directly and indirectly) to guide virtually all subsequent project management activities and project planning document preparation. Therefore, having viable project objectives is essential to overall project success. Project Scope Statement The project scope statement is prepared to describe the nature and extent of the work effort that will be performed to achieve project objectives. The scope statement is a broader characterization of how the project objectives will be achieved. Essentially, the scope statement indicates what is to be accomplished, when and where it will be accomplished, by which individuals or groups, and at what cost, schedule, and resource utilization thresholds. It can likewise be a statement of what won’t be achieved. That is, the scope statement places boundaries on the work effort. The challenge for the scope statement developer (again, ideally a team effort) is to neither understate the scope in a way that does not sufficiently guide the project nor overstate the scope so as to inundate readers, reviewers, and project team users with unnecessary detail and complexities that are better placed elsewhere, per haps in accompanying project plans. A simple project scope statement can be developed and is recommended for most projects. The simple scope statement identifies the high-level work effort (e.g., design and develop) using required or designated specifications and standards (e.g., Customer Spec #1) and producing the required deliver able (e.g., a blue widget). A more comprehensive project scope statement can be prepared to better discern the boundaries of the project work effort. To that end, it would have additional detail to address what is in scope and what is out of scope:
The level of simplicity or complexity applied in creating the project scope statement is a factor the performing organization needs to consider and specify in a policy or addendum to this practice guidance. Inasmuch as a simple scope statement is desired, it’s sometimes necessary to develop a more comprehensive scope statement relative to the complexity of the project, the expectations of the customer, or the nature of the business. Remember, however, that the project scope statement should be consistent with and indicative of how project objectives will be achieved. Project Initial Estimates Estimates prepared at this juncture in the project are referred to as Order of Magnitude estimates. That means they are generally within plus or minus 75% of the expected actual values. While this could represent the cost of almost two similar projects, this is widely accepted as a reasonable estimate because complete information about the project is not yet available, and the technical solution is not yet fully defined. Also remember, at this juncture, that we have not yet selected the project but are still trying to determine if it’s to be pursued. There will be more detailed planning and estimating after the project is selected. Project initial estimates can be prepared to include the following three primary elements: Initial Time Estimate -- This represents the first "guess" of what the project timeline will look like to achieve project work that is associated with specified high-level phases and activities. This estimate can be prepared in conjunction with the resource utilization estimate that follows, as the resource allocations made will influence the project work schedule. A basic approach to this estimate is to simply identify the major phases of the project as the basis for a timeline. If more detail is desired, this initial estimate could be prepared at the activity level, where more detail about the project effort is specified. Be sure to consider and include time estimates for the following types of activities:
Initial Resource Utilization Estimate This represents the first "guess" of what the project staffing requirements will be. Its focus is on identifying the types of resources needed, perhaps key resources as well as vendors and contractors that will be identified to conduct the project. Such resource utilization information will assist decision makers in their examination of resource availability, and which available resources will be allocated to the project. A basic approach to this estimate is to simply specify the number of resources that will be needed within the major phases of the project. If more detail is desired for this initial estimate, specific resources can be identified according to the timeline elements (phases and activities) established earlier, to include consideration of the following types of resources:
This represents the first "guess" of what the project will cost the performing organization, and represents a project investment that is expected to ultimately show financial returns to the organization. This effort should be performed by a team or an individual who is familiar with project cost elements. It’s also wise and highly recommended that a review of the project archives, particularly lessons learned, be conducted to examine prior project estimates on similar projects to see how well those estimates supported actual project performance. A basic approach to this estimate is to simply specify the overall costs that will be needed to conduct the major phases of the project. If more detail is desired for this initial estimate, major cost items can be identified according to the timeline elements (phases and activities) established earlier, to include consideration of the following types of costs:
See the separate project management practice area, Project Estimating, for more information and guidance on preparing project estimates. Project Deliverables Project deliverables are those products and services presented to the customer as a result of project work accomplished, and, to a large extent, they represent the achievement of specified project objectives. For project definition purposes, project deliverables are described at a high level and represent only those items that will be transferred to the customer. Therefore, internal or interim deliverables are not usually a part of the project definition, but they may be specified in accompanying plans when they are developed. Project deliverables are normally aligned with the completion of certain project activities, as may be specified in the Work Breakdown Structure, which is normally constructed during project planning. However, at this early juncture, usually only a general description of the deliverables can be identified. The project manager and other project definition preparers can then specify anticipated project deliverables within project phases. This list of project deliverables will need to be reviewed and refined as more detailed requirements and information from the customer are applied to the project planning effort. The specification and management of project deliverables are presented in greater detail in the separate project management practice area, Project Planning, under the Project Requirements Examination practice. Project Assumptions and Constraints Project definition provides an early description of what has to be accomplished in order to have a successful project outcome. Many of the project activities, events, and conditions that are initially considered are based on items such as "status quo," "common knowledge," "routine responses," and "reasonable expectations." These may be "common and reasonable," but since they are not necessarily factual, there could be alternate perspectives, and they need to be stated as the project's assumptions and constraints. Project Assumptions are factors considered to be true, real, or certain for the purposes of making project decisions. Assumptions involve a degree of risk. Examples of assumptions to be considered include specifications or statements related to: Dates when a key person is available; Budget and resource availability; Time requirements; Organizational structure and culture; Staff availability, training requirements, and experience; Number and identity of stakeholders; Level of project complexity; Size and duration of the project; External needs; Extent of risks Level of technical capabilities Assumptions made are not inherently project risks. However, the basis of each assumption must be checked to validate it. At the same time, if assumption validity is weak, it could become a project risk, and should be included for consideration in the project risk assessment that is performed. Notwithstanding, project assumptions are identified for the very fact that they are not factual but assumed conditions. Once identified, the validity of assumptions should be monitored during planning activities and throughout the project to ensure a reasonably sound basis for project decisions and direction. Project Constraints are generally known factors that will limit project management options. Specifically, constraints may restrict the planning of project cost, schedule, and resources needed to achieve the project scope; affect when or how an activity can be scheduled; or lead to team pressure to complete the project on time, within budget, and according to specification. Examples of constraints to be considered include Cost; Schedule; Staffing requirements or availability; Funding availability; Available technology; Contractual factors; Government regulations; Risk factors; Scope expectations and feasibility; Market or economic factors; Organizational structure; Organizational culture; Collective bargaining agreements; Preferences of the project management team; Similarly, constraints in and of themselves are not project risks. However, they could become risks if the constraining condition unexpectedly changes to affect project performance. Constraints should be monitored and validated on an ongoing basis. PROJECT CLASSIFICATION DEVELOPMENT It’s important for project management stakeholders to have a common frame of reference regarding the types of projects being performed. The establishment of a project classification scheme addresses this need. This determination is usually a part of the project governance function because it has distinct business implications. However, in the absence of a formal project classification system, this methodology will assist users in classifying their project using generic criteria. Conceptually ... The purpose of this practice is to specify the classification for every project in order to assist in describing the important characteristics of each project (i.e., an adjunct to Project Definition Development) and to allow stakeholders to immediately associate the importance of each project to the business. Project classification, when constructed with consideration for the business interests of the relevant organization, will be an aid in the following areas: Selecting, prioritizing, and managing projects in portfolio management; Aligning projects with business objectives; Identifying business and technical risks that may be encountered; Calculating levels of project work performed in different technical areas; Providing general indications of duration, resource requirements, and complexity; Identifying and assigning project managers with appropriate skill and experience; Qualifying team members for participation in the project effort; Selecting vendors and contractors for participation in the project effort; The use of a project classification scheme will convey a significant amount of information about each project in just a few words. Project Classification is normally conducted during project initiation (in the Profile Phase) but can be reviewed or updated at any time during the project. Project Classification Criteria The PMO or other governing body is normally responsible for creating and implementing an organization-wide project classification scheme. This is done when project classification criteria are developed to describe projects in the organization in terms of the business interests and the project work effort. This methodology prescribes a relatively simple yet fairly complete project classification scheme as a default, generic solution. The prescribed classification criteria can be modified to suit specific organizational needs. The project classification criteria presented will consider the four factors of business interest, project management level, project performance indicators, and project complexity indicators to classify projects. Each of these is discussed here. Business Interest--This criteria area refers to the importance of the project to the organization and prescribes five classification options: Operational Project--Work is conducted to fulfill operational needs, usually to develop or maintain internal operating capability. Innovation Project--Work is conducted to design or develop new products, services, or technology for subsequent internal use or external sale. Mandate Project--Work is conducted to satisfy the requirements of an internal (business) or external (industry or government) mandate. Customer Project--Work is conducted to provide product or service deliverables and to fulfill objectives specified by internal/external customers. Strategic Project--Work is conducted to achieve a marketplace position, or to achieve business expansion or another strategic objective. Project Management Level --This criteria area refers to the extent and complexity of project management needed to ensure project success and prescribes five levels of project management that could be associated with a given project: Level 1--Simple (routine) technical specialty requirements, and/or no business complexity Level 2--Advanced technical specialty requirements, and/or minimal to no business complexity Level 3--Multiple technical specialty requirements, and/or low business complexity Level 4--Unique or advanced technical specialty requirements, and/or moderate business complexity Level 5--Multiple advanced technical specialty requirements, and/or high business complexity Project Performance Indicators--This criteria area refers to project features that can help delineate project performance requirements, to include: Project duration--How long will the project take to complete? Project team size--How many resources will be assigned? Project value (cost)--How much will the project cost? How much will it earn? Project performance criteria are evaluated and rated in relative terms of very low, low, moderate, high, and very high. Weights are then assigned to each criteria level, and an overall value for project performance is calculated. Project Complexity Indicators--This criteria area refers to a combination of project and business factors that can help delineate project complexity requirements, to include: Strategic Value--A project becomes more complex when it becomes more important to business success. This element examines the alignment of the project with strategic business objectives, the level of importance associated with marketing efforts, and business factors such as net present value and cost-benefit analysis results. Business Risk--This factor considers the business risk produced primarily by external business influences, along with any technical risk associated with new product development, recurring project work, and development of state-of-the-art technology. Technology-The amount of technology that is introduced into the project will have an effect on the capability to provide the intended technical solution. This includes consideration of new technology, current technology, the likelihood of technology changes, and technology training requirements. Organization Scope--The number of business units participating in the project-including cross functional participation and external vendors and contractors, their locations considered-will affect project performance and project management requirements. Technical Scope--The depth or extent of technical expertise or specialization needed by assigned resources to properly conduct the project will affect project complexity. Project complexity criteria are similarly evaluated and rated in relative terms of very low, low, moderate, high, and very high. Weights are then assigned to each criteria level, and an overall value for project complexity is calculated. These four project classification areas should sufficiently identify projects in most organizations. Although there are various options, the intent is to provide a classification "code" that is generally recognized throughout the organization. A few examples using the default criteria in this methodology include: Project A Classification: Customer-3. The classification uses only the business interest and project management level of indicators. It tells users that this project is for an external customer that requires a small variety of technical services. Project B Classification: Operational-1. The classification again uses only the business interest and project management level of indicators. It tells users that this project is for an internal customer that requires only basic or limited technical capability. Project C Classification: Mandate-4/5. The classification uses the business interest and project management level of indicators, along with a summary value of the project performance and complexity indicators. It tells users that this project is mandated and it requires some advanced technical capability to perform. The additional indicator shows that this project has "above aver age" complexity. Project Classification Development can then be used to identify the type of projects being undertaken within the organization. It provides the common frame of reference that allows all key project participants (and project stakeholders) to recognize the type and nature of each project, and it facilitates decisions along the way. |
| Top of Page | More PM Articles | Prev: PM Methods of Practice | Next: Optimizing Project Selection | Info-Source.us |