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

• Capacity. The amount of work that can be completed within a certain time frame and is based on the number of hours that an individual or team will be available to complete the work.
• Sustainable pace. The pace that an Agile team can work at indefinitely without resulting in developer burnout (ideally 40 hours per week).
• Technical debt. refers to the obligation a development team incurs when they use a short-term, expedient approach to developing a software package without considering the long-term consequences. Technical debt increases project cost and complexity due to inefficiencies, inaccuracies, and other issues introduced into the software package. Poor management, incompetency, timeline pressure, or inadvertent mistakes can all contribute to technical debt.
• Big visible chart. A large chart displayed near the Agile team that show how the team is progressing. You could make a big visible chart to show defects, velocity (burndown chart), customer acceptance tests, or to find out how much time the team is wasting.
• Cycle. refers to the total amount of time it takes for a single task or work item to travel through the workflow from the beginning of work until it ships.
• Sprint plan. The tangible outcome of a Sprint planning meeting. The Sprint plan is a written document assembled by the development team and includes 1) the goal for the sprint—a brief description of the product or deliverable to be completed by the end of the sprint, and 2) a detailed list of the Product Backlog Items (PBIs) or user stories the team has committed to completing by the end of the sprint, based on the team’s availability and velocity. Each PBI or user story is broken down into tasks according to the priority set by the product owner and assigned to a team member.
• Sprint task. A single small item of work that helps one particular story reach completion.
• Work breakdown structure (WBS). A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.
• Workflow diagram. A graphical representation of activities and actions conducted by users of a system. (Sometimes called an activity diagram.)
• Work-in-progress limit (WIP). refers to work that is currently being developed and not yet ready to be released as a deliverable. For Scrum teams, this would apply to the work being accomplished during a sprint. For Kanban teams, this refers to work that has been pulled from the backlog and is being developed, indicated by cards in the ‘Doing’ or ‘Work-in-Progress’ column of the Kanban task board.

1. Activity. The smallest portion of an enterprise effort that has its own name, input, description, timeframe, and measurable result.

• Activity. A unit of work performed as part of an initiative or process.
• Activity diagram. A model that illustrates the flow of processes and/or complex use cases by showing each activity along with information flows and concurrent activities. Steps can be superimposed onto horizontal swimlanes for the roles that perform the steps.
• Burndown chart (or Burndown chart). The chart that represents all outstanding work. The vertical axis represents the backlog, while the horizontal axis represents time. The work remaining can be represented by story points, ideal days, team days, or other metrics.
• Burnup chart (or Burnup chart). The chart that tracks how much work has been completed. There are two lines on the chart—one line represents total work and the other represents work completed. The vertical axis represents the amount of work and can be measured in number of tasks, hours, or story points. The horizontal axis represents time, usually measured in days.
• Business process. A set of defined ad-hoc or sequenced collaborative activities performed in a repeatable fashion by an organization. Processes are triggered by events and may have multiple possible outcomes. A successful outcome of a process will deliver value to one or more stakeholders.
• Continuous integration (CI). A software engineering practice that involves continual integration of new development code into the existing codebase.
• Entity-relationship diagram. An entity-relationship diagram is a graphical representation of the entities relevant to a chosen problem domain, the relationships between them, and their attributes.
• Input. A material, service or support item that is processed by the system.
• Process map. A business model that shows a business process in terms of the steps and input and output flows across multiple functions, organizations, or job roles.
• Process model. A visual model or representation of the sequential flow and control logic of a set of related activities or actions.
• Process. A set of activities used to convert inputs into desired outputs.
• Process. simply the way someone works. Everyone has a process. It can be pre-defined, empiric or merely chaotic.
• Red route. The frequent and critical activities that users will perform on your site. They are complete activities, not single tasks, and will probably require several pages to execute. Defining the red routes for your site means that you’ll be able to identify and eliminate any usability obstacles on the key user journeys. (Important roads in London are known as ‘red routes’ and Transport for London do everything in their power to make sure passenger journeys on these routes are completed as smoothly and quickly as possible.)
• Relationship map. A business model that shows the organizational context in terms of the relationships that exist among the organization, external customers, and providers.
• Relationship. A defined association between concepts, classes or entities. Relationships are usually named and include the cardinality of the association.
• Sequence diagram. A type of diagram that shows objects participating in interactions and the messages exchanged between them.
• Task board. A physical or online visual representation of user stories broken down into tasks or work units. A physical task board can be as simple as a whiteboard with three columns labeled To Do, Doing, and Done; colored post-it notes or index cards representing tasks are placed in the column that reflects the task's current state. A task board can be expanded to hold more columns and can also include horizontal swim lanes.
• Task list. A list of tasks needed to complete the set of stories committed to a sprint.
• Task. A single unit of work broken down from a user story. A task is usually completed by just one person.
• Quality. The degree to which a set of inherent characteristics fulfills requirements.
• Total quality management. A philosophy of management that is driven by continuous improvement and responsiveness to customer needs and expectations.
• Quality assurance (QA). (1) The process of evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards. (2) The organizational unit that is assigned responsibility for quality assurance.
• Quality assurance. Activities performed to ensure that a process will deliver products that meet an appropriate level of quality.
• Unit production. The production of items in units or small batches.
• Slack time. The amount of time an individual activity can be delayed without delaying the whole project.
• Six Sigma. A quality program designed to reduce defects and help lower costs, save time, and improve customer satisfaction.
• Operational plan. A plan that encompasses a particular operational area of the organization.
• Process consultation. A meeting in which a consultant assists a client in understanding process events with which he or she must deal and identifying processes that need improvement.
• Process production. The production of items in continuous process.
• Process conflict. Conflict over how work gets done.
• Process conflict. A conflict over how work gets done.
• Specific plan. A plan that is clearly defined and leaves no room for interpretation.
• Standing plan. An ongoing plan that provides guidance for activities performed repeatedly.
• Short-term plan. A plan covering one year or less.
• Single-use plan. A one-time plan specifically designed to meet the needs of a unique situation.
• Budget. A numerical plan for allocating resources to specific activities.
• Budgeting. The process of allocating resources to pay for designated future costs.
• Directional plan. A plan that is flexible and sets out general guidelines.
• Formal planning department. A group of planning specialists whose sole responsibility is helping to write organizational plans.
• Long-term plan. A plan with a time frame beyond three years.
• Planning. Management function that involves setting goals, establishing strategies for achieving those goals, and developing plans to integrate and coordinate activities.
• Planning. A process that includes defining goals, establishing strategy, and developing plans to coordinate activities.
• Zero-balance budgeting. Process starting with an established point of zero rather than using the current budget as the basis for adding, modifying, or subtracting resources.
• Velocity. A metric that specifies how much work a team is able to complete within a single, fixed-length iteration or sprint.
• Timebox. A fixed period of time to accomplish a desired outcome.
• Timebox. An assigned period of time during which an individual or team works toward an established goal. The team stops work when the time period concludes, rather than when work is completed. The team then assesses how much work was accomplished toward the specified goal.
• Timeboxing. Setting a duration for every activity and having it last exactly that (i.e. neither meetings nor sprint are ever lengthened - ever).
• 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.

Methods

1. UX project process.
   • UX strategy stage. The stage during which the brand, guiding principles, and long-term vision of an organization are articulated. The strategy underpinning a UX project will shape the goals of the project—what the organisation is hoping to achieve with the project, how its success should be measured, and what priority it should have in the grand scheme of things.
   • UX research stage. Often referred to as the Discovery stage. Complex projects will comprise significant user and competitor research activities, while small projects may require nothing more than some informal interviews and a survey.
   • UX analysis stage. The stage of the UX process where insights are drawn from data collecting during the earlier Research stage. Capturing, organising and making inferences from The What can help UX designers begin to understand The Why.
   • Design stage. The stage in a user-centred design process where ideas for potential solutions are captured and refined visually, based on the analysis and research performed in earlier stages.
   • Production stage. The stage at which the high-fidelity design is fleshed out, content and digital assets are created, and a high-fidelity version of the product is validated with stakeholders and end-users through user testing sessions. The role of the UX Designer shifts from creating and validating ideas to collaborating with developers to guide and champion the vision.
2. Why-What-How sequence.
   • The Why. The statement for need or "why" the customer(s) want/think/need The What, possibly, in The How way.
   • The What. The statement for strategy or "what" is the best solution to satisfy The Why.
   • The How. The statement for tactic or "how" to accomplish The What.

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.