Project Management Quarter

Project Management Quarter (hereinafter, the Quarter) is the last of four lectures of Project Quadrivium (hereinafter, the Quadrivium):

• The Quarter is designed to introduce its learners to enterprise implementation, or, in other words, to concepts related to implementing enterprise design; and
• The Quadrivium examines concepts of administering various types of enterprises known as enterprise administration as a whole.

The Quadrivium is the first of seven modules of Septem Artes Administrativi, which is a course designed to introduce its learners to general concepts in business administration, management, and organizational behavior.

Lecture outline

The predecessor lecture is Product Design Quarter.

Concepts

1. Product life cycle.
   • Lifecycle. Important phases in the development of a system from initial concept through design, testing, use, maintenance, to retirement.

• Scenario. A narrative describing “a day in the life of” one of your personas, and probably includes how your website or app fits into their lives.
• Scenario. An analysis model that describes a series of actions or tasks that respond to an event. Each scenario is an instance of a use case.
• Commercial-off-the-shelf software (COTS). Software developed and sold for a particular market.
• Project charter. A document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.
• Project kick-off. The formally recognised start of a project.
• Project scope. The work that must be performed to deliver a product, service, or result with the specified features and functions. See also scope.
• Project. A temporary endeavor undertaken to create a unique product, service or result.
• Project. An activity having goals, objectives, a beginning and an end.
• Risk Management. A process of identifying what can go wrong and making plans that will enable a system to achieve its goals.
• Risk. An uncertain event or condition that, if it occurs, will affect the goals or objectives of a proposed change.
• Feature creep. The tendency to add additional requirements or features to a project after development is already underway. Feature creep can occur on either a project or sprint level.
• Release plan. The plan that outlines the features to be included in an upcoming release and provides an estimated date for the release. The plan should include responsibilities, resources, and activities required to complete the release.
• Release. The transition of an increment of potentially shippable product or deliverable from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it. A release can be either the initial build of a product or the addition of one or more features to an existing product. A release should take less than a year to complete, and in some cases, may only take three months.
• Sprint goal (aka Sprint theme). The key focus of the work for a single sprint.
• Sprint. A fixed-length iteration during which one user story or product backlog item (PBI) is transformed into a potentially shippable deliverable. Each sprint is assigned a set amount of time to be accomplished (sometimes referred to as Timeboxing), which could be anywhere from one week to one month, but typically lasts two weeks.
• Done done. A product increment that is considered potentially releasable; it means that all design, coding, testing and documentation have been completed and the increment is fully integrated into the system.
• Continuous improvement. A process of improving quality and efficiency by making small, incremental changes over time. In Kanban, continuous improvement refers specifically to the process of optimizing workflow and reducing cycle time, resulting in increased productivity.
• Beta launch. The limited launch of a software product with the goal of finding bugs before final launch.
• Deliverable. Any unique and verifiable work product or service that a party has agreed to deliver.
• Incremental delivery. Creating working software in multiple releases so the entire product is delivered in portions over time.

1. • Configuration management.

• Impediment backlog. A visible or nonvisible list of impediments in a priority order according to how seriously they are blocking the team from productivity.
• Impediment. Any obstacle that prevents an individual or team from completing a task or project. Unscheduled meetings, technical issues, lack of knowledge or expertise, a distracting workplace, and office conflict are all examples of impediments.
• Project management. The task of getting a project's activities done on time, within budget, and according to specifications.

1. • Project management. Practice and a set of concepts, based on that practice, that define culture of managing of projects from the moment when the project manager is identified to the project closing.

• Scheduling. Detailing what activities have to be done, the order in which they are to be completed, who is to do each, and when they are to be completed.

1. Enterprise effort. A determined attempt or a set of attempts undertaken in order to create outcomes of a work package, task, activity, project, operations, and/or enterprise.
   • Work package.
   • Activity.
   • Project. One or more enterprise efforts undertaken in order to create a unique deliverable, most features of which can be identified before the development starts.
   • Operations (or Ongoing operations). Repetitive enterprise efforts undertaken in order to create a specified deliverable or a batch of specified deliverables using already designed process.
   • DevOps. Practice and a set of concepts, based on that practice, that define culture of unifying software development (Dev) and software operations (Ops). Its signature toolchain represents a chain of tools that fit one of the following categories: (a) Code, (b) Build, (c) Test, (d) Package, (e) Release, (f) Configure, and (e) Monitor.
2. Task.
   • Task force (ad hoc committee). A temporary committee or team formed to tackle a specific short-term problem affecting several departments.
   • Task identity. The degree to which a job requires completion of a whole and identifiable piece of work.
   • Task identity. The degree to which a job requires completion of a whole and identifiable piece of work.
   • Task significance. The degree to which a job has a substantial impact on the lives or work of other people.
   • Task significance. The degree to which a job has a substantial impact on the lives or work of other people.
   • Task structure. One of Fiedler's situational contingencies that describes the degree to which job assignments are formalized and structured.
   • Task structure. The degree to which job assignments are procedurized.

• Requirements risk mitigation strategy. An analysis of requirements-related risks that ranks risks and identifies actions to avoid or minimize those risks.
• Requirements management plan. A description of the requirements management process.
• Requirements management. The activities that control requirements development, including requirements change control, requirements attributes definition, and requirements traceability.

1. Estimation. The process of assigning a quantifiable measure to the amount of workload needed to complete a project or task, in order to determine the duration, effort, or cost required to complete the project or task.
   • Relative estimation. One of several types of estimations Agile teams use to determine the amount of effort needed to complete project tasks. Tasks or user stories are compared against equivalent, previously completed tasks or group of tasks of similar difficulty.
   • Planning poker. A team building exercise or game used to arrive at a group consensus for estimating workload based on the Delphi method.

Roles

1. Project manager. The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.
2. Developer. Developers are responsible for the construction of software applications. Areas of expertise include development languages, development practices and application components.

Instruments

1. Sprint retrospective. A meeting held following the completion of a sprint to discuss whether the sprint was successful and to identify improvements to be incorporated into the next sprint.
   • Sprint retrospective. A session where the Team and Scrum Master reflect on the process and make commitments to improve.

Results

1. Project management plan.

Practices

This lecture concludes the Quadrivium. Since the next, third module of the Course is Operations Quadrivium; thus, the successor lecture is Business Inquiry Quarter.