Deliverable

Last updated

A deliverable is a tangible or intangible good or service produced as a result of a project that is intended to be delivered to a customer (either internal or external). [1] [2] A deliverable could be a report, a document, a software product, a server upgrade or any other building block of an overall project. [3] A deliverable may be composed of multiple smaller deliverables. It may be either an outcome to be achieved (as in "The corporation says that becoming profitable this year is a deliverable") or an output to be provided (as in "The deliverable for the completed project consists of a special-purpose electronic device and its controlling software").

Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time.

In sales, commerce and economics, a customer is the recipient of a good, service, product or an idea - obtained from a seller, vendor, or supplier via a financial transaction or exchange for money or some other valuable consideration.

Some deliverables are dependent on other deliverables being completed first; this is common in projects with multiple successive milestones. [4] In this way many time-savings are possible, shortening greatly the whole project final supply term. This designing activity can be represented in the drawings with a "cloud" around a not yet designed part which means: "this part (size, or other characteristics) will be studied later". The part settled can be "delivered" to the interested parties.

A deliverable differs from a project milestone in that a milestone is a measurement of progress toward an output, whereas the deliverable is the output delivered to a customer or sponsor. [5] For a typical project, a milestone might be the completion of a product design, while the deliverable might be the technical diagram or detailed design report of the product.

Milestones are tools used in project management to mark specific points along a project timeline. These points may signal anchors such as a project start and end date, or a need for external review or input and budget checks.

In technical projects, deliverables can be further classified as hardware, software, or design documents. In contracted efforts, deliverable may refer to an item specifically required by contract documents, such as an item on a contract data requirements list or mentioned in the statement of work.

Computer hardware physical components of a computer system

Computer hardware includes the physical, tangible parts or components of a computer, such as the cabinet, central processing unit, monitor, keyboard, computer data storage, graphics card, sound card, speakers and motherboard. By contrast, software is instructions that can be stored and run by hardware. Hardware is so-termed because it is "hard" or rigid with respect to changes or modifications; whereas software is "soft" because it is easy to update or change. Intermediate between software and hardware is "firmware", which is software that is strongly coupled to the particular hardware of a computer system and thus the most difficult to change but also among the most stable with respect to consistency of interface. The progression from levels of "hardness" to "softness" in computer systems parallels a progression of layers of abstraction in computing.

Software non-tangible executable component of a computer

Computer software, or simply software, is a collection of data or computer instructions that tell the computer how to work. This is in contrast to physical hardware, from which the system is built and actually performs the work. In computer science and software engineering, computer software is all information processed by computer systems, programs and data. Computer software includes computer programs, libraries and related non-executable data, such as online documentation or digital media. Computer hardware and software require each other and neither can be realistically used on its own.

In engineering, technical documentation refers to any type of documentation that describes handling, functionality and architecture of a technical product or a product under development or use. The intended recipient for product technical documentation is both the (proficient) end user as well as the administrator / service or maintenance technician. In contrast to a mere "cookbook" manual, technical documentation aims at providing enough information for a user to understand inner and outer dependencies of the product at hand.

Related Research Articles

Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include the process of executing a program or application with the intent of finding software bugs, and verifying that the software product is fit for use.

Work breakdown structure deliverable oriented decomposition of a project into smaller components (in project management and systems engineering)

A work-breakdown structure (WBS) in project management and systems engineering, is a deliverable-oriented breakdown of a project into smaller components. A work breakdown structure is a key project deliverable that organizes the team's work into manageable sections. The Project Management Body of Knowledge defines the work-breakdown structure "A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables."

Program management or programme management is the process of managing several related projects, often with the intention of improving an organization's performance. In practice and in its aims, program management is often closely related to systems engineering, industrial engineering, change management, and business transformation. In the defense sector, it is the dominant approach to managing very large projects. Because major defense programs entail working with contractors, it is often called acquisition management, indicating that the government buyer acquires goods and services by means of contractors. The Defense Acquisition University (DAU) in Ft. Belvoir, Virginia is the word's leading educator in managing major programs.

Requirements analysis Engineering process

In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

Systems development life cycle Systems engineering term

The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system. The systems development lifecycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: analysis, design, development and testing, implementation, documentation, and evaluation.

Product lifecycle

In industry, product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from inception, through engineering design and manufacture, to service and disposal of manufactured products. PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise.

Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, empirical knowledge, and continual improvement, and it encourages rapid and flexible response to change.

Enterprise content management (ECM) extends the concept of content management by adding a time line for each content item and possibly enforcing processes for the creation, approval and distribution of them. Systems that implement ECM generally provide a secure repository for managed items, be they analog or digital, that indexes them. They also include one or more methods for importing content to bring new items under management and several presentation methods to make items available for use.

Software product management is the discipline of building, implementing and managing software or digital products, taking into account life-cycle considerations and an audience. It is the discipline and business process which governs a product from its inception to the market or customer delivery and service in order to maximize revenue. This is in contrast to software that is delivered in an ad hoc manner, typically to a limited clientele, e.g. service.

Acquisition initiation (ISPL)

Acquisition Initiation is the initial process within the Information Services Procurement Library (ISPL) and is executed by a customer organization intending to procure Information Services. The process is composed of two main activities: the making of the acquisition goal definition and the making of the acquisition planning. During the acquisition initiation, an iterative process arises in which questions about the goal of the acquisition are usually asked. In response to these questions the Library provides details of the requirements, covering areas such as cost, feasibility and timelines. An example of such requirements is the "planning of the acquisition", a component that may also lead to more questions about the acquisition goal.

Scrum is an agile framework for managing knowledge work, with an emphasis on software development. It is designed for teams of three to nine members, who break their work into actions that can be completed within timeboxed iterations, called sprints, no longer than one month and most commonly two weeks, then track progress and re-plan in 15-minute time-boxed stand-up meetings, called daily scrums.

Actuate Corporation is a publicly traded reporting, analytics and customer communications software company based in San Mateo, California, part of the San Francisco Bay Area and Silicon Valley. The company is known for its creation of the open source Eclipse BIRT business data reporting project launched by the Eclipse Foundation in 2004. Actuate software helps businesses and OEMs worldwide serve their customers within the finance, government, manufacturing, telecommunications, and healthcare industries, among others.

Functional specification

A functional specification in systems engineering and software development is a document that specifies the functions that a system or component must perform.

Cap Gemini SDM

Cap Gemini SDM, or SDM2 is a software development method developed by the software company PANDATA in the Netherlands in 1970. The method is a waterfall model divided in seven phases that have a clear start and end. Each phase delivers (sub)products, called milestones. It was used extensively in the Netherlands for ICT projects in the 1980s and 1990s. PANDATA was purchased by the Capgemini group in the 1980s, and the last version of SDM to be published in English was SDM2 in 1991 by CAP GEMINI PUBLISHING BV. The method was regularly taught and distributed among Capgemini consultants and customers, until the waterfall method slowly went out of fashion in the wake of more iterative extreme programming methods such as Rapid application development, Rational Unified Process (RUP) and Agile software development.

V-Model (software development)

In software development, the V-model represents a development process that may be considered an extension of the waterfall model, and is an example of the more general V-model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction, respectively.

Integrated master plan

In the United States Department of Defense, the Integrated Master Plan (IMP) and the Integrated Master Schedule (IMS) are important program management tools that provide significant assistance in the planning and scheduling of work efforts in large and complex materiel acquisitions. The IMP is an event-driven plan that documents the significant accomplishments necessary to complete the work and ties each accomplishment to a key program event. The IMP is expanded to a time-based IMS to produce a networked and multi-layered schedule showing all detailed tasks required to accomplish the work effort contained in the IMP. The IMS flows directly from the IMP and supplements it with additional levels of detail——both then form the foundations to implement an Earned Value Management System.

A specification often refers to a set of documented requirements to be satisfied by a material, design, product, or service. A specification is often a type of technical standard.

A phase-gate process, is a project management technique in which an initiative or project is divided into distinct stages or phases, separated by decision points.

Business requirements are specifications which once delivered, provide value, it describes the characteristics of the proposed system from the viewpoint of system end user like a CONOPS and is also called stakeholder requirements specification (StRS). Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems.

References

  1. Kermit Burley. " What Is a Deliverable in Project Management?". Houston Chronicle . Small Business section. Hearst Corporation, 2013.
  2. "Goal: Define project deliverables". Microsoft Office website. Accessed December 9, 2013.
  3. Cutting, Thomas. "Deliverable-based Project Schedules: Part 1". PMHut.com (Last accessed 8 November 2009).
  4. What is a Deliverable in Project Management? Wrike. Accessed 8 August 2017.
  5. Bernie Roseke, What is a Project Deliverable?. Project Engineer, 22 November 2016. Accessed 8 August 2017.