| HOME Software Testing Data Mining and Warehousing |
|
A project is organized and structured to satisfy requirements and to achieve specified work in a specified period of time, and within a specified budget. Translating requirements into solutions necessitates project planning that will provide direction for skilled people to accomplish the work that produces the desired project outcome. Project planning is also needed to enable responsible and capable individuals to subsequently manage the progress of that project work. Preceding the actual planning effort, it’s necessary to gain a comprehensive understanding of what is needed and what should be attained or achieved through the project work effort. This represents the identification and examination of Project Requirements that are used to guide project planning activities. Then, a Technical Solution is developed as a high-level description of how project requirements will be fulfilled. Work elements are then defined, and a project Work Breakdown Structure (WBS) is constructed. There are three practices associated with project planning:
Estimates of project cost, schedule, and resource utilization are normally prepared in a concurrent manner (see the separate Project Estimating practice area). When these estimates are incorporated into the work elements of the WBS, a project work plan is created, and that plan provides the capability to implement and manage the preferred technical solution. The project planning practices provide the primary input in the creation of the project work plan-the fundamental document required to perform project management (see the separate Project Work Plan Development practice section under the Project Management Plans practice area). PROJECT REQUIREMENTS EXAMINATION The identification of requirements is a necessary beginning to the project planning process for every project. It specifies the project outcomes to be achieved, usually in terms of system, product, or service deliverables. Project requirements provide the specification of the desired project outcome-what is it, along with the specification of its business purpose, functional capability, and technical dimensions and description. This information provides the basis for project planning, assists in project management, and guides project technical work. It provides a common frame of reference for all stakeholders relative to the customer's expectations about the project's deliverables. This frame of reference warrants the communication, collaboration, and validation activities that are prescribed when identifying project requirements. Conceptually ... This practice provides the project manager, the executives and senior management team, the project team, the vendors, the customer, and the organization with a specification of what is required for a successful project outcome. Project requirements will particularly become the guiding reference for managing the quality aspects of the project. The purpose of this practice is to guide the performance of activities that are used to compile, analyze, and validate the requirements for each project. Project Requirements Examination prominent activities are normally done in conjunction with the early activities of Project Planning (Plan Phase). However, preliminary work with requirements actually begins when requirements information is first gathered and compiled during Project Initiation (Profile Phase). This practice prescribes four primary activities associated with the examination of project requirements:
These activities are described below. Requirements Gathering: The process of gathering requirements represents the identification of one or more information sources, the methods or approach that will be used to obtain requirements from each source, and the specification of the type of information that is needed from each source. Project requirements gathering can be conducted using the following methods and sources. Statement of Work --Project requirements may be directly or indirectly specified in the statement of work issued by the customer. The statement of work may be included as a part of solicitation materials or be a stand-alone document. It may also be found, in some cases, included with a customer's work order or purchase order, or it may be inherently represented by the work order or purchase order itself. The statement of work can be a source of requirements information for less technical and less complex project work, or it could represent a higher-level specification of requirements for such technical and complex project work. The statement of work should be reviewed with sufficient examination to identify any specified project deliverables or other requirements. Request for Proposal (RFP)--The RFP document, as well as similar matter such as the Request for Information (RFI) and Request for Quote (RFQ), should be reviewed for content that describes project requirements. This type of document issued by the customer could include sections that present a statement of work, listing of project deliverables, or reference to technical standards and specifications. The RFP needs to be adequately reviewed to identify direct or indirect references to project requirements. Technical Specifications --Technical specifications usually provide a more detailed description of the product or deliverable that should result from project performance. The "technical" nature of the specification usually implies a reference to a level of detail or descriptive that can be used to create the technical aspects of the end product or deliverable. The technical specification, however, can sometimes include information that is used across business, technical, and functional types of requirements. The technical specification can also include direct or indirect references to standards that are applicable to the nature of work to be pursued. Any technical specifications for the project need to be used as the "blueprint" for creating the end product or deliverable, to include addressing requirements for their technical composition, operating features, functional capability, and business application. Business Specifications--Business specifications provide guidance for conducting the project relative to business-type requirements. This could represent a wide range of business-related requirements and include such elements as…
Business requirements are used prominently in constructing the business solution but may also surface as elements of the project work plan, which should include such business-related project management activities. Surveys and Analyses--Surveys and analyses are sources of requirements information that deal primarily with technical-type requirements. They provide a means to fine-tune or otherwise create specifications for the technical solution, and could include…
Surveys and analyses are used to decompose and clarify high-level technical requirements or to construct the technical solution based primarily on referenced industry or technical standards. Workshops --Workshops provide a structured and facilitated approach to the specification of business, technical, and functional requirements. They bring together relevant participants who discuss and deliberate the requirements for a project, and who jointly decide on the needed requirements set. Workshop participants can be a homogeneous group or include representation from both internal and external organizations having diverse interests in the project's outcome. Workshop participants should be chosen for their expertise in the technical nature of the project. Workshops can be used to conduct many of the group-based surveys and analyses activities that were mentioned in the previous paragraph, or they may be conducted as self-structured requirement development meetings. Interviews --Interviews provide for requirements collection based primarily on one-on-one conversations with relevant project stakeholders, which are very often the end users. The interview process begins with the development of a standard questionnaire that will be used by the interviewer, includes the scheduling and conduct of interview meetings with selected individuals, and concludes with an examination and analysis of interview results and outcomes. While one-on-one contact is the normal interview approach, team or group interviews can also be conducted to generate early consensus in the determination of requirements. Some may consider such a group interview to be more aligned with the workshop method for gathering requirements. Requirements Documentation and Analysis The process of documenting and analyzing requirements is simply one that lists all of the requirements associated with a project and examines them regarding how, when, and where they will be applied to project work. This "specification" of requirements enables the project manager to align and plan project work toward the accomplishment of each project requirement. As may be needed, this process enables requirements to be decomposed into discrete statements that are then tracked and monitored for fulfillment. It also enables requirements to be aligned with specific WBS work elements. Requirements analysis includes the following actions: Requirements Statement Examination --Each decomposed requirements statement is reviewed for clarity and completeness-does it describe a requirement that is understood? Each statement is also examined for stability-will the requirement remain the same through fulfillment, or will it become subject to change during project execution? To that end, this examination may prompt an assessment of project risks associated with the stability of requirements. Cross-Requirement Examination --The collection of requirements statements is compared to determine if there is any repetition or potential redundancy that could cause incorrect references to be made. This step also examines the collection to identify any conflicts or inconsistencies across specified requirements. Requirements Identification --Each requirement is assigned a unique identifier for tracking and monitoring purposes. Requirements Type Designation --Each requirement is aligned with one of the types of requirements that are distinguished in the organization. The following are the default requirement types used in this methodology:
The organization can use these, modify or expand them for better fit in the organization, or create its own requirements types that best serve its management needs. In turn, each requirement can be managed relative to the "type category" in which it’s placed. Each requirements statement can have specified actions or characteristics that are associated with a certain requirements type. E.g., the following characteristics could be aligned with requirements types: Area of Responsibility--requires business, technical, or project management oversight Source of Requirement-indicates the individual or organization that prescribed the requirement and that will serve as a point of contact for clarification or change Requirement Specification Document-indicates the requirement's reference document that contains the requirements description or complete requirements statement Testability-indicates that requirement testability can be used to determine fulfillment Standard or Regulation-indicates association with a particular industry standard or government mandate The specification of requirement designations and the alignment of these or other requirements-type characteristics is an organizational action taken in conjunction with methodology deployment. WBS Alignment --Each WBS work element, at least at high levels of work decomposition, are aligned with the requirement to be fulfilled. Requirements Validation and Approval The process of validating project requirements is one of review and feedback to the project manager (or other requirements managers). It’s a process of communicating defined requirements and receiving feedback information regarding how well the requirements are perceived to satisfy needs and fulfill expectations. In general, project requirements validation is an effort to examine and confirm three things: Specified requirements are verifiable. There is consistent understanding among key stakeholders of what is to be accomplished, recognition that it can be realistically accomplished, and agreement regarding what will indicate that the requirement has been fulfilled, as supported by the following: The project manager and customer have the same perspectives on requirements. The project manager and customer both agree that the requirements are realistic. The project manager and customer have established completion criteria. Specified requirements are discernable. Prepared requirements statements provide adequate indications of boundaries to reduce or eliminate scope creep. Specified requirements are independent. Prepared requirements statements can be examined independently, don’t present conflict or opposition to other specified requirements, and independently and sufficiently describe the result to be achieved. Some of the methods just prescribed for identifying project requirements can also be used to validate project requirements. Also, other methods and objectives can be implemented. In turn, prominent managers in the performing organization and in the customer's organization should establish for themselves sufficient understanding of the project requirements to enable them to sign off and approve the requirements baseline. Requirements Baseline Setting The process of requirements baseline setting provides an initial and ongoing reference to approved project requirements. It includes the following general activity elements: Project Stakeholder Review--Project requirements are examined by primary project stakeholders (e.g., the project manager and project executive) to gain appreciation for the project effort, but also to review the project requirements validation that has been conducted. In this review, stakeholders can view and understand the bases for specific project deliverables, and, when uncertainty arises, they can elevate their concerns for additional consideration by the customer and the project approval authority. In essence, this is a final project requirements validation step. Project Authority Review and Approval --Project requirements come to the project approval authority following their validation. At such time, the requirements should be clear and specific, and they provide a quick under standing for the level of project authority used. Each organization may designate approval authority in the project business plan, project charter, or other document, according to established organizational business practices or as per the classification of the project. This could include authority granted to or retained by the Project Control Board
An approved set of project requirements enables detailed project planning to begin. Project Requirements Baseline Establishment --The approved set of project requirements represents a base line that is referenced when creating the project solution and associated work plan. The baseline is subject to somewhat rigorous change control procedures, as may be implemented for the project at hand. As well, all work conducted on the project is directly or indirectly related to the project requirements baseline, and project plans are monitored and managed to ensure that they address all elements of the project requirements baseline. TECHNICAL SOLUTION DEVELOPMENT The project technical solution presents a description of the project work to be accomplished, and specifies the milestones and deliverables associated with that work. It’s used to guide the technical work effort but is also valuable for use by non technical managers as a means to ascertain the level of effort and progress. Conceptually ... This Technical Solution Development practice provides the project manager and customer with a general specification of work to be performed by the project team, as dictated by project requirements. It presents the organization's approach to achieving the statement of work provided by the customer. It often contains a description of the major project phases but may also contain more detailed descriptions of work elements as well as the steps needed to fulfill project requirements. The level of detail is usually determined by the project manager, consistent with customer needs and organizational practices. The purpose of this practice is to provide a basis for constructing the project WBS, which is the key component of the Project Work Plan. To that end, the technical solution is often included as the "technical approach" in the technical portion of any proposal submitted to the customer for consideration. The technical solution is normally done during Project Planning (Plan Phase). However, it should be reviewed and updated as necessary throughout the project. Preparing the Technical Solution The technical solution is the descriptive element of the project. It can be a broad and general written statement or a very detailed written description of the work to be performed. The technical solution will frequently describe the work to be accomplished at the phase level of a project, and thereby it helps to define or otherwise identify those phases. To that end, the technical solution carries much of the related information contained in the project definition to the next level of detail. Sometimes, as per local practices or project man ager determination, the technical solution will also describe project activities and tasks within each project phase. When this greater level of detail is achieved, the information is then ready for entry into the WBS. Preparing the technical solution prompts the use of action verbs, which is similar to the content of the WBS. It’s the first attempt to specify project work actions, particularly at the activity and task levels. The technical solution will be used to guide the construction of the WBS, and is an intermediate step between specifying requirements and developing the WBS. In-as-much as the technical solution represents a high-level or abbreviated view of work to be performed, it can be used to illustrate the project to project stakeholders and other individuals who don’t require the details of a WBS examination. Specifying Project Milestones Project milestones are the technical solution elements that provide a means to monitor and track critical activities associated with the technical solution. By definition, milestones are zero-time events; they have no duration. Rather, they serve as indicators of such matters as Completion of specific work actions Progress of specific work assignments Passage of increments of time Measurement of increments of cost Achievement of resource utilization objectives Transfer of project deliverables Project milestones are used to indicate project progress at a high level. They are often imbedded in the work break down structure to show progress without showing each and every work element. When the work breakdown structure is filtered to display only milestones, this provides a means for senior managers and executives to peruse project progress without examining all of the details contained in the WBS. In some organizations, milestones are used to represent deliverables and show the timely (or delayed) transfer of project deliverables to the client. However, such "deliver able milestones" can be incorporated on their own merit, as described in the following section. The organization should identify the type of milestones it wants to monitor, and the project manager can also identify and include personal preferences for milestones during development of the technical solution. Specifying Project Deliverables Project deliverables are the technical solution elements that identify what the client will receive as a result of the project effort. Deliverables will likely be a product, a service, or an automated system (or hardware or software component). More precisely, a deliverable is any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project. Project deliverables are the output of the project work packages defined in the WBS and are normally linked directly to the work packages they fulfill. The project manager, in collaboration with the customer, can use the following concepts when specifying project deliverables: Begin the specification of deliverables based on any preliminary deliverables listed in the project definition (scope statement). Consider the following when specifying project deliverables:
Answers to these simple questions will contribute to better planning of work efforts that will produce each deliverable. Address the following conditions when specifying deliverables: Determine whether adequate cost, duration, and resource utilization estimates can be developed for the identified deliverable at the work package level. Determine if the complete deliverable can be defined in tangible, verifiable terms at the work package level, or if only deliverable components can reside there. Determine if the deliverable can be appropriately scheduled and budgeted at the work package level. Determine whether the deliverable can be assigned to an individual, an organizational unit, or an external vendor, or otherwise can remain within the immediate purview of the project manager. Address the need for specifying deliverables other than customer deliverables: Is there a need to specify any internal deliverables resulting from project management activities (e.g., project plans, reports, etc.)? Is there a need to specify any internal deliverables resulting from organizational mandates (e.g., reviews, audits, performance reports, etc.)? Is there a need to specify any interim deliverables resulting from partial work on or component development of customer deliverables (e.g., system component-A to the overall customer system deliverable)? The project manager should carefully plan the inclusion of each project deliverable following these considerations. The project's customer and stakeholders will judge the performance of the project by the quality and timeliness of the deliverables. Above all, the project manager must ensure that each deliver able meets the needs and requirements of the project. Project deliverables can then be imbedded as "deliverables" or as "deliverable milestones" in the WBS. This can be done in a way that allows the progress of deliverables to be tracked and reported (in a filtered view) for review by senior managers, executives, customers, and other project stakeholders. CONSTRUCTION of WORK BREAKDOWN STRUCTURE The WBS represents the specification and decomposition of project work, normally to the work package level-the lowest level of work at which cost, duration, and resource utilization are assigned. The WBS is normally a deliverable oriented group of project work elements that organizes and defines the total scope of the project. Any work that is not contained in the WBS is considered to be outside the scope of the project. Conceptually ... This practice enables project planners to translate the project definition elements, particularly the project objectives and scope statement, into discrete work steps to be performed. It provides the project manager, project team, and customer with a breakdown of all work to be accomplished by the project, and a means to monitor those accomplishments. It facilitates coordination and collaboration of work between project team members and across project stakeholders, and establishes a common frame of reference for those communicative processes. The project manager and project team can use the WBS to accomplish:
The WBS is widely considered to be the most essential tool needed for effective project management. Developing a realistic project work plan is not possible without first developing a WBS that identifies each project work element that will be used to achieve project objectives. The WBS is normally developed during Project Planning (Plan Phase). However, it should be reviewed and updated as necessary throughout the project. Preparing for WBS Development The first step in preparing the project's WBS is a review of the project definition. This review should provide high-level insight and guidance for developing the WBS. Project planners should conduct this review to include an examination of:
Preliminary project and business risks Ideally, the interim steps of preparing a more detailed project requirements document and a technical solution (as discussed in previous sections) are accomplished for each project. When available, these documents do represent a translation of the project definition contents for use in planning the project work effort. Project planners should use these items along with a review of project definition elements when preparing for construction of the WBS. Developing the WBS Structure The WBS breaks down a project's activities and tasks into the lowest achievable level that can be budgeted, scheduled, assigned to resources, and ultimately evaluated. Each descending level represents an increasingly detailed description of the project's work elements. Project work is often decomposed according to the following structure: Project --The highest level at which the work effort to be performed is identified and distinguished from other work efforts in the organization. Phase --The specification of a very high-level component of project work; where there are usually about four-seven phases specified for each project (e.g., plan, design, develop, test, transfer, accept, etc.), according to the technical nature of work to be performed. The technical nature of work is then contrasted with the phases of the project management methodology to ensure that all essential project management activities are also included in the project WBS. Phases can over lap, and their combined timeline duration represents the duration of the entire project. Activity--The specification of a higher-level component of project work; where it represents a collection of subordinate work elements that usually have some similarity in the nature of work performed, a common product, system component, or service result to be derived, or other work-based relationship. The activity level represents the roll-up or aggregation of all work elements below it in the structure. Therefore, every activity will have at least two sub-elements of work. One sub-element of work would merely be the activity itself, as per the concept of work roll-up or aggregation. Task--The specification of a more detailed component of project work; where it represents either a discrete work effort or a roll-up or aggregation of two or more lower-level work efforts that have some common skill, knowledge, or labor effort applied. Again, a sole sub element of work would only be the task itself, as per the concept of work roll-up or aggregation. Subtask--The specification of a very low-level component of project work; where there is usually a significantly homogeneous work effort performed. This structure can be used across most small, mid-size, and even some larger projects. Very large projects and so-called "mega projects" could require additional work element levels to be defined, and this structure can be decomposed further by using additional subtask levels. Also, any naming convention can be applied to these structure elements as long as such terminology is communicated widely and used uniformly across the organization. There are two additional concepts to consider when structuring project work. The first is the concept of "work package," and the second is the concept of "cost account." Work Package--The work package is the level at which all cost, schedule, and resource utilization estimates are created. The project work package is a discrete element of work that represents the lowest level where work is assigned and project progress is tracked. Project management tradition has evolved to show (and some standards promote) that a work pack age should be performed in no more than 80 hours to be fully manageable. This "80-hour rule" applies to most medium-size projects. However, for larger, more complex projects costing several millions of dollars, defining the lowest WBS level at 80 hours can be unrealistic in some circumstances. Sometimes a work package becomes several weeks or even several months in duration for "mega projects." For smaller projects, an 80-hour work effort may actually be too much time, when only one day or a few hours are needed to complete the work effort. Project planners should use the "80-hour rule" when possible but reconcile use of a smaller or larger work package duration when necessary. Each work package should produce some discern able output or "deliverable" for the project, which is not necessarily the deliverable for the customer. Sometimes a work package is created to represent distribution of project work to an individual or to a specific team, giving them an assignment for achieving a desired work package outcome or "deliverable." It can also be used to show development of a component of the customer's deliverable. Also, the work package can be used to specify work needed to accomplish internal project management and planning "deliverables" associated with the project. Cost Account--The cost account is the level in the project work structure that is used to provide guidance and information to the functional areas in the organization that will account for the costs associated with the project work effort. It will normally reside in the structure at one level above the work package level. For a medium-size project, this would be the activity level. The cost account provides a means to estimate budgets and to track, monitor, and control the work being conducted within each cost account. Therefore, in contrast to the use of work packages cited earlier, the cost account would normally be used to show work elements that are distributed or outsourced to external vendors and contractors, and it could also show work elements distributed to other teams within the organization. Project planners should use the concepts presented here to construct the WBS, which can be created in a variety of formats. This methodology suggests consideration of two prominent format options: Outline Format--An outline format is a detailed task list incorporating numbers corresponding to each WBS activity, task, and subtask work element. This format is the most common one for developing and building a WBS, where each level of indent indicates a lower level of work effort. The outline format organizes the project work by defining all the tasks that must be performed for each activity and at each phase of the project life cycle. As the levels become more distinct, all the activities and tasks, along with any subtask or lower efforts to be accomplished, are identified. This depicts a simple WBS outline format. Gantt Chart Format --The Gantt chart format trans poses the WBS from outline form to a horizontal bar chart with a time dimension, which is useful for developing and monitoring the project schedule. This depicts a simple WBS Gantt chart format. Please note how lower-level work efforts aggregate or roll up to comprise the next higher work element. Sometimes it’s useful to combine these two format options, as is done when using any of today's project management software applications. These applications present the WBS outline and Gantt chart formats side by side. They also present a variety of other WBS and project schedule formats that can be selected by the user. Also, most automated applications will help the user to create the WBS. This is done effectively when work is entered at the lowest, work package level. Then, the user identifies related or similar work packages for aggregation or roll-up, and uses the application to combine them. As this is done, the application will also automatically calculate the duration for all successively higher work element levels, which is the "combined duration" of lower-level work elements. The convenience and accuracy of this calculation will rely on ensuring that all work element relationships (e.g., predecessors) are properly defined at the work package level. === WBS Outline Format WBS Element # Activity and Task Level 1.0 Plan Project (Phase) 1.1 Develop Work Plan (Activity) 1.1.1 Prepare Project Work Plan (Task)-Cost Account 1.1.1.1 Construct WBS (Sub-Task)-Work Package 1.1.1.2 Incorporate Estimates (Sub-Task)-Work Package 1.1.2 Prepare Support Plans (Task)-Cost Account 1.1.2.1 Prepare Risk Plan (Sub-Task)-Work Package 1.1.2.2 Prepare Quality Plan (Sub-Task)-Work Package WBS outline format. ==== WBS Gantt Chart Format WBS Element # Activity and Task Timeline WEEK 1--WEEK 2--WEEK 3--WEEK 4--WEEK 5--WEEK 6 1.0-Project 1.1-Activity 1.1.1-Task 1.1.1.1 1.1.1.2 1.1.2-Task 1.1.2.1 1.1.2.2 WBS Gantt chart format. === Constructing the WBS The actual construction of the WBS is generally accomplished using one of two prominent approaches: the top down (analogy) approach or the bottom-up approach. Top-Down WBS Construction Approach-In the top-down approach, project activities and tasks are sequentially decomposed into related work package work elements. Using this approach, all major project phases are first broken down according to the primary activities to be performed. Then, those activities are further decomposed to the task and subtask levels, as needed, until the work package level is developed as a work element that can be reasonably monitored and managed. It’s at the work package level that planners should incorporate cost, schedule, and resource utilization estimates. Continue the decomposition until the capability to introduce that information is reasonably achieved. A rule of thumb is to create work packages at a level where work accountability can be assigned and managed. Bottom-Up WBS Construction Approach--The bottom-up approach begins with the identification of all the work elements needed to fulfill project objectives and manage the project to completion. These tasks (and subtasks) are then combined into related groupings, which are then rolled up or aggregated to the higher activity level. In turn, related activities are aggregated to the phase level, and so on, to the project level. This approach is best accomplished by a planning team or members of the project team who will actually perform the work. It often begins by using group brainstorming techniques to identify as many of the required project work elements as possible. Then, as the team proceeds to aggregate related work elements, any gaps or missing work elements can be identified and incorporated into the structure. Again, it’s at the lowest levels of work, the work package, that cost, schedule, and resource utilization estimates are introduced. When constructing the WBS by either approach, project planners should ensure that it accurately defines the entire project effort. Essentially, if a work effort is not included in the WBS, you should not expect that it will be accomplished. Conversely, only work that is considered within the scope of work should be included in the WBS. Project management involves the planning of work to be performed and then managing that plan for work accomplishment within the allotted cost, time, and resource avail ability. To that end, the project WBS is the fundamental tool of project management. Whatever format the WBS ultimately takes, a project simply cannot be effectively managed without it. As the WBS is constructed, it’s worth noting a few tools that are similar to the WBS in format but that are used to manage additional project information: Contractual Work Breakdown Structure (CWBS)--A decomposition of work that describes a total product and the associated work to be accomplished on a specific contract; it often includes identifying the level of reporting and delivery provided to the customer. Organizational Breakdown Structure (OBS)--A decomposition of work elements as per assignments to specific organizational units, vendors, and some times individuals. Resource Breakdown Structure (RBS)--A decomposition list of project work as per assignments to the specific resources; a variation of the OBS. Bill of Materials (BOM)--Describes and quantifies, in hierarchical pattern, the list of physical materials, parts, and components required to manufacture a product at the assembly or subassembly level. Project Breakdown Structure (PBS)-Serves the same purpose as the WBS, and this term is often applied when the BOM is incorrectly identified and used as a WBS. Once created, the WBS can be refined at points where estimates are incorporated, and thereby the WBS is translated into the Project Work Plan. See more information regarding how this translation or transition is accomplished in the project estimating and project planning practice areas. |
| Top of Page | More PM Articles | Prev.: Optimizing Project Selection | Next: Optimal Project Estimating | Info-Source.us |