Project Deliverables Checklist
Project deliverables checklist provides a quick overview of the project deliverables, which can be used as a tracking tool. It may also include the key responsible and accountable parties to ensure timely completion of the project deliverables or to achieve the milestones. Maintaining one comprehensive checklist, for tracking, enables the project manager to be on top of the key activities, deliverables and emerging issues.
A project deliverables checklist can be organized or categorized by project management and product delivery management process groups. You can track the project progress using the checklist and the milestones timeline. You may drill down, using the project schedule, to track details, particularly when you detect signals or control thresholds which may impact project delivery time, cost or quality. A concise checklist for tracking the project deliverables or milestones completion, responsibility and accountability, including the delegation of authority, is critical to staying focus and on track. Table 13 includes a reference or link to the project control checklist template.
| | |
Table 13 – Project deliverables checklist template
| PPMGuideDeliverResultPPM_ProjectControlChecklist.doc |
Incoming search terms:
- project deliverables checklist
- project deliverable checklist
- Deliverables Checklist
- Project delivery checklist
- deliverable checklist
- work breakdown glossary
- project plan including time lines breakdown structure roles and responsibilities
- project deliverables checklist template
- deliverable checklist template
- kick-off meeting agenda template
Categories: Managing Outcome Tags: Project Deliverables Checklist deliverables checklist
Project Agenda | Mandate
Project Agenda | Mandate
The project agenda is the first working document (optional, but recommended) you should create when you are assigned to play the role of a project manager or lead a project. You may call it a name that makes sense to you, the key here is the purpose and content of the document. It enables the project manager to have a good understanding of the project goals, scope, deliverables, cost and time constraints, and stakeholders’ expectations. This working document will be useful in creating or updating other key project documents, such as project charter and integrated project plan, and managing the project. It is particularly useful in a situation where the project charter has not been created.
The components of the project agenda document include:
§ Project profile: includes project name, enterprise unique number or ID, goal, description, approved project budget, time constraint, project manager, sponsor, champion and client’s organization.
§ High level deliverables: list of deliverables required to deliver the desired outcome.
§ Stakeholders’ information: includes stakeholders’ contact information and stakeholder-influence matrix (discussed in Part 4 – Project Management, see page 74).
§ Communication checklist: includes stakeholder group information needs, format and frequency.
Table 9 includes a reference or link to the project agenda template.
Table 9 – Project Agenda Template
| PPMGuideDeliverResultPPM_ProjectAgenda.doc |
Depending on the project, some of the contents of the project agenda document could be extracted from the project charter (if it exists) and rolled over to the integrated project plan document.
Categories: Managing Outcome Tags: project agenda project mandate
Product Delivery Management – Industry Specific
Project management cuts across different industries, while product delivery management is industry specific. The matured industry specific product delivery management processes, including their interactions with the project management processes, will be briefly described.
Product delivery management processes and practices fulfill the delivery of new, enhanced or modified products within the product life cycle. It begins at the conceptualization phase, progressing to design, development, production and commercialization. The vital role of project management is to ensure that well thought through processes and practices are applied to ensure that the right product is delivered, using the appropriate product delivery management processes and practices.
Some organizations have integrated or harmonized the project management and product delivery management processes into a unified framework. However, this does not preclude the separate significance of the two related but interdependent disciplines.
Sometimes, the product delivery organization may be an external service provider. Therefore, it is advisable to have a contract document or agreement, signed by the project manager and the product delivery manager, defining the product specifications and governing the expectations.
Information Management and Technology
The methodologies described here are used to develop custom built solutions and implement Commercial Off-The-shelve Solutions (COTS). To understand the delivery of Information Technology (IT) based solutions (application, data/information, security and infrastructure), it is important to briefly describe some de-facto industry frameworks or methodologies that are commonly used and adapted to deliver these solutions.
In most organizations, particularly in small to medium size organizations, the complete understanding of these frameworks is rare. This is because some part of the organization focuses on the application of one or some of the frameworks, without a good appreciation of the complements that others provide. Understanding these frameworks, including their applications and how they complement each other, is very important to establish and sustain service excellence.
COBIT – Governance/Management
Control OBjectives for Information and related Technology (COBIT) is an IT governance, service planning, delivery, control and support framework. COBIT is a set of best practices and framework for information technology (IT) management created by the Information Systems Audit and Control Association (ISACA), and the IT Governance Institute (ITGI) in 1992. COBIT provides managers, auditors, professionals and information technology users with a set of generally accepted measures, indicators, processes and best practices to assist them in maximizing the benefits derived through the use of information technology and developing appropriate IT governance and control in the organization. Detailed information on COBIT is available at the isaca.org website.
Figure 20 shows a representation of the COBIT 4.1 framework. COBIT 4.1 has 34 high level processes that cover 210 control objectives categorized in four domains – Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate. COBIT provides benefits to managers, IT users, professionals and auditors. Managers benefit from COBIT because it provides them with a foundation upon which IT related decisions and investments can be based on. It provides the IT professionals with the framework to deliver products and services that maximize value for the users of IT products and services.
COBIT provides end-to-end picture of IT products and services delivery and management. Its understanding will enable a project manager to appreciate the relevance of project delivery within the overall context of IT service delivery.
Figure 20 – COBIT Framework – An Overview Representation
Information Systems Delivery Methodology – SDLC
System Development Life Cycle (SDLC) is a tested and widely used IT based business solutions development methodology. It provides the framework for structuring, planning, designing, developing and delivering information systems. The traditional SDLC phases are feasibility study, requirement analysis, design, development (construction), testing, implementation and post implementation review.
Variations of the traditional SDLC exist, with customized characteristics. However, the goal of each variation or type is the same – to deliver information technology solutions that meet the defined and agreed client requirements or needs in a timely and cost effective fashion. Figure 21 is a representation of the SDLC framework. It shows the processes and their associated deliverables.
Figure 21 – System Development Life Cycle (SDLC)
Information Systems Delivery Methodology – RUP
Rational Unified Process (RUP) is an IBM® version of the SDLC. It has been proven to be reliable for conceptualizing, analyzing, designing, developing and deploying IT based business solutions. It supports different approaches (waterfall, iterative or mixed) to solutions delivery. Figure 22 is a representation of the RUP methodology. It shows the processes and their associated deliverables.
Figure 22 – Rational Unified Process (RUP)
Information Systems Delivery Methodology – Approach
There are two basic approaches to developing and delivering IT based business solutions – waterfall and iterative. Variations of these two, particularly iterative, exist. The focus here is on these two basic approaches.
Waterfall: This a sequential, though with some overlaps, approach to transform user requirements into system specifications, design, development and delivery of a solution that meets the user requirements. It is generally adopted in matured environments where user requirements are known to a high degree, with high confidence and minimal or no change in the course of solution or product development.
Iterative: This is a progressive incremental approach to developing information systems. It is commonly used for new product development, where requirements are not well established and need to emerge over time. The SDLC method is applied in phases to elicit stage by stage, analysis, design and development of known requirements into a solution. It goes through series of progressive iterations where additional requirements are identified, sometimes through proto-types.
The SDLC (or RUP) methodology does not prescribe a specific approach. The SDLC is used, albeit in different fashion, in both waterfall and iterative approaches. Figure 23 and Figure 24 show the use of the SDLC methodology in the waterfall and iterative approaches respectively.
Figure 23 – Product Delivery Management, SDLC Waterfall
Figure 24 – Product Delivery Management, SDLC Iterative
Infrastructure Delivery Methodology
Infrastructure includes hardware and software (operating system, middle ware, support and utility software). It is the platform on which the business solutions (application and data) run. It requires specific or customized fit-for-purpose methodology to ensure consistent delivery and sustenance.
ITIL (Information Technology Infrastructure Library, currently at version 3) is a de-facto service delivery and management framework which can be used or customized to deliver and manage infrastructure products and services. Also, the RUP methodology can be adapted to deliver infrastructure projects.
Basically, infrastructure product or service delivery follow these processes – inception (requirements specification), design/capacity planning, acquisition of equipment, software and service support, implementation and transition to operations.
Figure 25 shows an infrastructure delivery framework.
Figure 25 – Infrastructure Delivery
Notes:
SLA è Service Level Agreement is the service support or sustainment (contractual) agreement between an organization and the (third party) service delivery partner or organization.
OLA è Operational Level Agreement is the service support or sustainment (contractual) agreement between the service delivery teams within the same organization. For example, an OLA may exist between the application development/maintenance and technology/hosting service delivery teams.
Information Systems Delivery Methodology – COTS
Commercial Off The Shelve (COTS) products are third party solutions that can be purchased, configured and/or customized to meet the client needs. Examples of COTs include SAP (System Application Program) – an enterprise resource planning and industry solutions portfolio, Oracle® Financials and PeopleSoft HR. Figure 26 shows a COTS delivery framework.
COTS delivery framework can be categorized into two parts: (i) Plan & Acquire and (ii) Delivery (Plan, Organize & Implement).
Plan & Acquire includes the following key elements:
- Product delivery strategy: a decision has to be made by the organization to build or buy a new product, based on the organization’s strategy or a specific need.
- Requirements specification: for COTS solution, the requirements have to be defined and specified in great detail to ensure that the right or best-fit product is selected for implementation.
- Evaluation checklist: this is derived from the requirements specification. It presents the requirements in format that facilitate features comparison across the selected third party products.
- Product Selection: products are selected for evaluation based on preliminary reviews (e.g. request for information and vendors’ demonstration) of possible products.
- Evaluation: evaluation of selected products is performed using the evaluation checklist. A product, with the lowest trade-off, is usually selected based on the evaluation result and recommendation.
- COTS decision and acquisition: this is a procurement process to acquire the selected product(s), usually through the request for proposal (RFP) activities.
Delivery (Plan, Organize & Implement) includes the following key elements:
- Delivery Plan: the main deliverable of delivery planning is the solution blueprint for the infrastructure setup and software configuration.
- Implementation: includes setup of test-bed for customization and/or configuration, training, pilot, testing, pre-production packaging, acceptance and production release.
- Transition: includes creation of support agreements, commission, decommission and post-production release review.
Construction
Construction projects vary in type, discipline, complexity and size. Construction project types include new product or asset, existing product maintenance and replacement or infrastructure renewals. Some maintenance work, depending on the size and organization, may not be treated as project, but rather as a minor work order, which usually takes less than 30 days to complete. An example of a minor work order is the repairs of a minor fracture on a portion of a local road.
Construction projects usually involve professionals from various disciplines (mechanical, electrical, civil and chemical engineering, finance, information technology etc.) working together at various stages of the project.
Examples of construction projects include:
§ Transportation – road construction, maintenance or renewal.
§ Housing/Building – home, office, school construction, maintenance or renewal.
§ Factory/industrial construction.
§ Chemicals – flow station, refinery construction, maintenance or renewal.
§ Electrical – new power station, sub-station and new transmission lines.
§ Mechanical – new automobile production or re-branding, new aircraft for department of defense.
Essentially key processes for a typical construction project include:
§ Requirements – Requirement Specifications.
§ Planning & Conceptual Design.
§ Procurement / Contract Administration.
§ Detailed Design.
§ Construction & Delivery (Acceptance).
§ Commission/Decommission.
Figure 27 shows a construction product delivery management framework.
Figure 27 – Construction Product Delivery Management
Incoming search terms:
- information security product delivery management
- iterative product delivery applied to products
Key Success Skills – Financial
“Sometimes one pays most for the things one gets for nothing.” Albert Einstein
No one wants to pay for things that do not provide a convincing and expected value. Every project must demonstrate its worth, else it could be considered of little or no value. A project manager needs a reasonable understanding of the project financial responsibility to demonstrate to the key stakeholders, particularly the sponsor, that the project is on track to deliver the desired outcome at the agreed and expected cost, time and quality. Treat it as a typical seller-buyer relationship. Essentially, you need solid understanding of project estimation and budgeting, financial performance tracking/monitoring and reporting.
Project Estimation and Budget
Project estimate is usually prepared by the project portfolio management group, prior to formal project approval and initiation, as part of the project conceptualization and business case development. A project manager needs good understanding of project cost estimation to ensure that cost accuracy, within tolerable limits, is maintained during the project life cycle, due to changes in scope and other factors such as inflation, technology etc. Organizations establish tolerable limits using the cost contingency range (measured in percentage) at different stages of the project life cycle.
The preferred or recommended approach to building the project cost estimate, which the client can relate to, is the result based costing. Result based costing is based on the project deliverables. This approach enables the client and stakeholders to trace the cost of delivering the desired project outcome.
Building the Cost Estimate
A professional will ensure that all costs are captured and avoid any attempt to hide cost in order to secure acceptable funding. Underestimation is a recipe for disaster, a major reason for project failure or mediocre outcome. Overestimation is neither a good thing, avoid it.
Underestimation and overestimation usually occur due to incompetency, organization attitudes or undue influence to control cost in a generic way. For example, the use of across the board cost cutting, which usually impact those who have done due diligence to present realistic cost. People tend to overestimate to catch up with the across the board cost cutting tactics. It is prudent to provide honest and valid estimate you can stand by and defend. Clients disrespect all attempts to overestimate or provide cost without clear justification.
Experienced, knowledgeable and ethical professionals know the importance of sound estimate that can be defended. For cost estimation you may use the top-down approach for a start and validate with a bottom-up approach. Otherwise, you should build the project cost using the bottom-up approach, which enables you to minimize cost contingency or changes in the future.
The key considerations for successful cost estimation include the following:
§ Requirements – the key determinant of what the project will likely cost.
§ Stakeholders/human capital – chargeable fees, resource types and rates.
§ Materials/Equipment – capital and operating assets, facilities and tools.
§ Administration – the overhead cost for managing the project and delivering the product.
Figure 17 shows a result based project cost estimation guide. The approach maps all cost to deliverables, which are combined to deliver the desired project outcome.
Notes on Over/Under Estimation
- Overestimation and underestimation should be avoided. Underestimation is rare, overestimation is common. The consequences of both are not desirable.
- Underestimation usually results in the delivery of poor or low quality product.
- Overestimation could be considered fraudulent. Sometimes it could be just to cover unexpected issues and risks. However, avoid situation where it could lead to project abandonment.
- Underestimation to reduce time and cost may end up costing you more money and time. Do not try to be ‘penny wise and pound foolish’.
- Do not provide estimate based on unclear needs or scope. Ask questions; do due diligence and state assumptions clearly.
- Cost may change; base it on justifiable or defendable reasons.
You might be thinking this is not real and no big deal, but a seriously business minded organization frown at careless estimates and you may loose respect over time. Even organizations which do not take their estimates seriously will do when they are dealing with limited resources and contending priorities.
Figure 17 – Cost Estimation Guide
Table 7 includes a reference or link to a result based cost estimation workguide template.
Table 7 – Cost Estimate Template
| PPMGuideProjectManagementPPM_CostEstimateTemplate.xls |
Financial Performance Tracking and Reporting
“Not everything that counts can be counted and not everything that can be counted counts.” Albert Einstein
A financial report should focus on what is relevant and useful for the stakeholders. Trying to report all possible financial records could overwhelm the audience and may dilute or hide vital information for decision making. The importance of relevant and valuable financial information cannot be understated. The content of a financial report, including the template, is discussed in Part 6 (Deliver Result).
Delegation of Authority (DOA)
Delegation of Authority (DOA) stipulates guidelines and rules to ensure quality of financial and related activities, by enforcing limited accountability at different assignment levels within the organization. This is a major requirement for auditing and responsible enforcement of financial dealings and service request approvals. It is not about whether or not you are trusted, it is about due diligence to ensure efficient and effective project cost performance tracking and prevent undue abuse of assigned roles and responsibilities.
As a project manager, you need to understand the DOA for your organization in order to effectively plan and secure approvals of key financial related activities for your project(s). You should accommodate the DOA reviews and approvals turn-around in the project plan (schedule). The DOA key elements are included in the Project Checklist section, Part 6 (Deliver Result).
