Difference between revisions of "Project Management Quarter"

From CNM Wiki
Jump to: navigation, search
(Concepts)
 
(215 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Project Management Quarter]] (hereinafter, the ''Quarter'') is the last of four lectures of [[Project Quadrivium]] (hereinafter, the ''Quadrivium''):
+
[[Project Management Quarter]] (hereinafter, the ''Quarter'') is a lecture introducing the learners to [[product management]] primarily through key topics related to [[project management]]. The ''Quarter'' is the last of four lectures of [[Business Quadrivium]], which is the second of seven modules of '''[[Septem Artes Administrativi]]''' (hereinafter, the ''Course''). The ''Course'' is designed to introduce the learners to general concepts in [[business administration]], [[management]], and [[organizational behavior]].
*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==
 
==Lecture outline==
''The predecessor lecture is [[Product Design Quarter]].''
+
''[[Business Modeling Quarter]] is the predecessor lecture.  In the [[enterprise planning]] series, the previous lecture is [[Concept Management Quarter]].''
  
 
===Concepts===
 
===Concepts===
*[[Version control]]. The task of organizing a system or product containing many versions.
+
#[[File:Ba-pm-se.png|400px|thumb|right|[[Business analysis]] vs [[project management]] vs [[systems engineering]]]]'''[[Project management]]'''. Practice and a set of concepts, based on that practice, that define culture of managing of [[project]]s from the moment when the [[project manager]] is authorized and up to the project closing.
*[[Production environment]]. A term describing the setting where a product is put into use by customers on a regular basis.
+
#*[[Project scope]]. The work that must be performed to produce a [[deliverable]] with the specified features and functions.
*[[Sprint]]. A set time period during which milestones must be reached and work must be completed and ready for review.
+
#*[[Planning fallacy]].  
*[[Release]]. A functional product sent to customers.
+
#[[File:Solution-project.png|400px|thumb|right|[[Problem]], [[solution]], and [[project]]]]'''[[Project]]'''. One or more [[enterprise effort]]s undertaken to create a unique [[deliverable]], functional features of which are identified or can be identified before the ''efforts'' start. Any [[project]] can be viewed as a set of [[process]]es.
*[[Milestone]]. A scheduled event to mark the completion of a major element of a product. Milestones are flags to signify that some amount of work has been completed.
+
#*[[Agile project]]. (1) A [[project]] which [[project scope]] cannot be predicted and defined; (2) The [[project]] that is developed using an [[Agile methodology]]. An [[Agile project]] is usually completed in several iterations or development cycles. Each iteration is reviewed and critiqued by the project team, which should include representatives of the project's various stakeholders. Insights gained from the critique of an iteration are used to determine what the next step should be in the [[project]].
*[[Deployment]]. Introduction of a new activity, procedure, or program to an organization.
+
#*[[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.
*[[Deliverable]]. A tangible outcome produced by a project. Internal deliverables are created by a project and are used by the company itself. External deliverables are created for clients, stakeholders, or customers. A single project can create many sets of deliverables.
+
#*[[Project kick-off]]. The formally recognized start of a project.
*[[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.
+
#'''[[Statement of work]]''' ([[statement of work|SOW]]). A formal document that either (1) defines the entire scope of the work that shall be completed in order to implement the [[proposed change]] or (2) describes [[deliverable]]s to be supplied under [[contract]].
*[[Sustainable pace]]. The pace that an Agile team can work at indefinitely without resulting in developer burnout (ideally 40 hours per week).
+
#'''[[Project life cycle]]'''. A collection of generally sequential project phases whose name and number are determined by the control needs of the organization or organizations involved in the project.
*[[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.
+
#*[[Project phase]]. A collection of logically related project activities, usually culminating in the completion of a major deliverable.
*[[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.
+
#*[[Project schedule]]. The planned dates for performing activities and the planned dates for meeting milestones.
*[[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.
+
#*[[Program]]. A group of related projects managed in a coordinated way. Programs usually include an element of ongoing work.
*[[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.
+
#'''[[Project life-cycle phase]]'''.
*[[Sprint task]]. A single small item of work that helps one particular story reach completion.
+
#*[[Inception phase]].  
*[[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.
+
#*[[Elaboration phase]].
*[[Workflow diagram]]. A graphical representation of activities and actions conducted by users of a system. (Sometimes called an activity diagram.)
+
#*[[Construction phase]].  
*[[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.
+
#*[[Transition phase]].
#[[Activity]]. The smallest portion of an [[enterprise effort]] that has its own name, input, description, timeframe, and measurable result.
+
#[[File:Iteration-backlog.png|400px|thumb|right|[[Iterative development]]]]'''[[Iterative development]]'''. The process of breaking down projects into more manageable components known as iterations. Iterations are essential in Agile methodologies for producing a potentially shippable deliverable or product.
*[[Activity]]. A unit of work performed as part of an initiative or process.
+
#*[[Iterate]]. The act of repeating a process with the aim of approaching a desired goal, target or result. Each repetition of the process is also called an iteration.
*[[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.
+
#'''[[Iteration]]'''. A [[phase]] of agile development in which a deliverable (or the solution overall) is progressively elaborated upon. Each [[iteration]] is a self-contained "mini-project" in which a set of activities are undertaken, resulting in the development of a subset of deliverables, a set of features, or potentially shippable [[deliverable]]. An [[iteration]] takes a fixed or timeboxed period of time, generally spanning two to four weeks. A typical [[Agile project]] consists of a series of [[iteration]]s, along with a [[Sprint planning meeting]] prior to development and a [[Sprint retrospective]] at the end of each [[iteration]]. Each iteration generally contains activities such as [[analysis]], [[design]], [[development]], and [[testing]]. For each [[iteration]], the team plans its work, does the work, and checks it for quality and completeness. [[Iteration]]s can occur within other [[iteration]]s as well. For example, an iteration of requirements development would include elicitation, analysis, specification, and validation activities. [[Iteration]]s are referred to as [[Sprint]]s in [[Scrum]].
*[[Burndown chart]] (or [[Release burndown chart|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.
+
#[[File:Scrum.png|400px|thumb|right|[[Sprint]]]]'''[[Sprint]]'''. A fixed-length time period during which a [[milestone]] is expected to be reached. Usually, one [[user story]] or [[product backlog item]] ([[product backlog item|PBI]]) must be transformed into a potentially shippable [[deliverable]] and ready for review. Each [[sprint]] is assigned a set amount of time to be accomplished (sometimes referred to as [[timebox]]), which could be anywhere from one week to one month, but typically lasts two weeks. In the [[Agile methodology]], [[Sprint]]s are referred as [[iteration]]s.
*[[Burnup chart]] (or [[Release burnup chart|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.
+
#*[[Sprint goal]] (aka [[Sprint theme]]). The key focus of the work for a single sprint.
*[[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.
+
#'''[[Product backlog]]'''. (1) A set of [[user story|user stori]]es, [[requirement]]s or features that have been requested by the customer and identified as candidates for potential implementation, prioritized, and estimated. The product backlog is not a ''to-do'' list; rather, it is a list of all the features the customer has requested be included in the project. The requirements include both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the [[product owner]] to prioritize the product backlog. During a [[Sprint planning meeting]], backlog items are moved from the product backlog into a sprint, based on the [[product owner]]'s priorities. A [[product backlog]] is a changing list of product requirements based on the customer's needs. The backlog is not a to-do list; rather, it is a list of all the desired features for the product. The Agile team uses the [[product backlog]] to prioritize features and understand which features to implement first.  
*[[Continuous integration]] (CI). A software engineering practice that involves continual integration of new development code into the existing codebase.  
+
#*[[Sprint backlog]]. A segment of [[product backlog item]]s ([[Product backlog item|PBI]]s) that the team selects to complete during a Scrum sprint. These [[product backlog item|PBI]]s are typically [[user story|user stori]]es taken from the [[product backlog]].
*[[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.
+
#*[[Backlog grooming]]. The process that occurs at the end of a sprint, when the team meets to make sure the backlog is ready for the next sprint. The team may remove [[user story|user stori]]es that aren’t relevant, create new stories, reassess priority, or split [[user story|user stori]]es into smaller tasks. Backlog grooming is both an ongoing process and the name for the meeting where this action occurs (a backlog grooming meeting).
*[[Input]]. A material, service or support item that is processed by the system.
+
#*[[Product backlog item]] ([[Product backlog item|PBI]]). A single element of work that exists in the product backlog. PBIs can include [[user story|user stori]]es, epics, specifications, bugs, or change requirements. The [[product owner]] of an Agile team compiles and prioritizes the product backlog, putting the most urgent or important [[Product backlog item|PBI]]s at the top. [[Product backlog item|PBI]]s comprise tasks that need to be completed during a Scrum sprint. A [[Product backlog item|PBI]] must be a small enough increment of work to be completed during a single sprint. As PBIs move up to a higher priority in the product backlog, they are broken down into user stories.
*[[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.
+
#'''[[Velocity]]'''. A metric that specifies how much work a team is able to complete within a single, fixed-length iteration or sprint.
*[[Process model]]. A visual model or representation of the sequential flow and control logic of a set of related activities or actions.
+
#*[[Work 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.
*[[Process]]. A set of activities used to convert inputs into desired outputs.
+
#*[[Sustainable pace]]. The pace that an Agile team can work at indefinitely without resulting in developer burnout (ideally 40 hours per week).
*[[Process]]. simply the way someone works. Everyone has a process. It can be pre-defined, empiric or merely chaotic.
+
#*[[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.
*[[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.)
+
#'''[[Release]]'''. A functional product sent to customers. In other words, [[release]] is the transition of an increment of potentially shippable product or [[deliverable]] from the development team into routine use by [[customer]]s. [[Release]]s typically happen when one or more [[sprint]]s has resulted in the [[market exchangeable]] having enough value to outweigh the cost to deploy it. A [[release]] can be either the initial build of a [[market exchangeable]] or the addition of one or more features to an existing [[market exchangeable]]. A [[release]] should take less than a year to complete, and in some cases, may only take three months.
*[[Relationship map]]. A business model that shows the organizational context in terms of the relationships that exist among the organization, external customers, and providers.
+
#*[[Beta launch]]. The limited launch of a software product with the goal of finding bugs before final launch.
*[[Relationship]]. A defined association between concepts, classes or entities. Relationships are usually named and include the cardinality of the association.
+
#*[[Incremental delivery]]. Creating working software in multiple releases so the entire product is delivered in portions over time.
*[[Sequence diagram]]. A type of diagram that shows objects participating in interactions and the messages exchanged between them.
+
#*[[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.
*[[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.
+
#*[[Deployment]]. Introduction of a new activity, procedure, or program to an organization.
*[[Task list]]. A list of tasks needed to complete the set of stories committed to a sprint.
+
#'''[[Change management]]'''. (1) The management of change and development within an [[enterprise]]; (2) The controlled identification and implementation of required changes within a computer system; (3) [[Change-control management]].
*[[Task]]. A single unit of work broken down from a user story. A task is usually completed by just one person.
+
#*[[Enterprise change management]]. Practice and a set of concepts based on that practice of preparing and supporting of [[enterprise]]s, their [[stakeholder]]s and [[technology]] in making [[enterprise change]].
*[[Unit production]]. The production of items in units or small batches.
+
#*[[Adaptive management]]. [[Management]] that stresses an importance of extensive monitoring and quick adjustments to newly-discovered data, particularly using the [[collaborating, learning and adapting]] method. Management adjustments are routinely employed in international development programs, especially conducted in environments that are unstable and in transition. [[USAID]] defines [[adaptive management]] as "an intentional approach to making decisions and adjustments in response to new information and changes in context."
*[[Slack time]]. The amount of time an individual activity can be delayed without delaying the whole project.
+
#'''[[Impediment]]'''. Any hindrance, obstruction, and/or 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.
*[[Operational plan]]. A [[plan]] that encompasses a particular operational area of the organization.
+
#*[[Impediment backlog]]. A visible or nonvisible list of impediments in a priority order according to how seriously they are blocking the team from productivity.
*[[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.
+
#*[[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.
*[[Process production]]. The production of items in continuous process.
+
#'''[[Change impediment]]'''. An [[impediment]] in implementing a [[change]].
*[[Process conflict]]. [[Conflict]] over how work gets done.
+
#*[[Change integration impediment]]. A [[change impediment]] related to challenges to integrate the [[proposed change]] into the existing infrastructure and carry out the change through technology.
*[[Process conflict]]. A [[conflict]] over how work gets done.
+
#*[[Change navigation impediment]]. A [[change impediment]] related to challenges to manage the change implementation over time, which is referred to as navigation.
*[[Specific plan]]. A [[plan]] that is clearly defined and leaves no room for interpretation.
+
#*[[Change resistance]]. A [[change impediment]] related to resistance originated from [[change resistance source]]s.
*[[Standing plan]]. An ongoing [[plan]] that provides guidance for activities performed repeatedly.
+
#'''[[Configuration management]]'''. [[Enterprise effort]]s undertaken in order to establish and further manage consistency of a product's or [[system]]'s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
*[[Short-term plan]]. A [[plan]] covering one year or less.
+
#*[[Version control]]. The task of organizing a system or product containing many versions.
*[[Single-use plan]]. A one-time [[plan]] specifically designed to meet the needs of a unique situation.
+
#*[[Continuous integration]] ([[Continuous integration|CI]]). A software engineering practice that involves continual integration of new development code into the existing codebase.
*[[Budget]]. A numerical plan for allocating resources to specific activities.
+
#'''[[Change resistance source]]'''. A cause of one's resistance to change.<blockquote><table class="wikitable" width=100%><tr><td style="text-align:center;">Category</td><th>[[Change resistance source]]</th></tr><tr><th>[[Individual's change-resistance source]]</th><td><ul><li>[[Habit]]. Any settled tendency or usual way of behavior.</li><li>[[Personal security]]. One's freedom from [[fear of the unknown]].</li><li>[[Economic conservatism]]. The tendency to prefer an existing economic stability to change.</li><li>[[Fear of the unknown]]. An unpleasant emotion caused by anticipation or awareness of danger that the upcoming change may bring.</li><li>[[Reaffirmation tendency]]. An inclination toward favorable perception of something that reaffirms one's attitudes.</li></ul></td></tr><tr><th>[[Enterprise change-resistance source]]</th><td><ul><li>[[Group inertia]]. [[Group]]'s tendency to do nothing or to remain unchanged.</li><li>[[Structural inertia]]. [[Organizational structure]]'s tendency to do nothing or to remain unchanged.</li><li>[[Limited focus of change]]. One's concern that the [[proposed change]] could be limited down to a small part of an [[enterprise]], which cannot be changed without changing other interrelated parts.</li><li>[[Threat to expertise]]. A possibility to lose one's expertise gained in an existing situation as a result of [[change]].</li><li>[[Threat to established power relationships]]. A possibility to damage existing power relationships as a result of [[change]].</li></ul></td></tr></table></blockquote>
*[[Budgeting]]. The process of allocating resources to pay for designated future costs.
+
#*[[Individual's change-resistance source]]. Any [[change resistance source]] that concerns an individual.
*[[Directional plan]]. A [[plan]] that is flexible and sets out general guidelines.
+
#*[[Enterprise change-resistance source]]. Any [[change resistance source]] that concerns an enterprise.
*[[Formal planning department]]. A group of planning specialists whose sole responsibility is helping to write organizational plans.
+
#'''[[Change-control management]]'''. Practice and a set of concepts based on that practice of [[change control]].
*[[Long-term plan]]. A [[plan]] with a time frame beyond three years.
+
#*[[Change control]]. A formal procedure used to ensure that changes to [[agreement]]s and their derivatives, especially [[requirement baseline]]s, are introduced in a controlled and coordinated manner in order to ensure that no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted and that resources are used efficiently. Usually, the [[performing organization]] is responsible for [[change-control management]], but the [[change control board]] makes decisions whether to approve, decline, or modify [[request for change]]s.
*[[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.
 
#*[[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.
 
#*[[Project management]]. Practice and a set of concepts, based on that practice, that define culture of managing of [[project]]s 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.
 
#'''[[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 effort]]s undertaken in order to create a unique [[deliverable]], most features of which can be identified before the development starts.
 
#*[[Operations]] (or [[Operations|Ongoing operations]]). Repetitive [[enterprise effort]]s undertaken in order to create a specified [[deliverable]] or a batch of specified [[deliverable]]s 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.
 
#'''[[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.
 
#'''[[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===
 
===Roles===
 
#'''[[Project manager]]'''. The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.
 
#'''[[Project manager]]'''. The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.
 +
#'''[[Idea champion]]'''. An individual who takes on a particular [[change]] and actively and enthusiastically promote the [[change idea]], build support, overcome resistance, and ensure that the [[change]] is implemented.
 +
#'''[[Change agent]]'''. An individual who acts as a catalyst and assumes the responsibility for supporting [[proposed change implementation]].
 
#'''[[Developer]]'''. Developers are responsible for the construction of software applications. Areas of expertise include development languages, development practices and application components.
 
#'''[[Developer]]'''. Developers are responsible for the construction of software applications. Areas of expertise include development languages, development practices and application components.
 +
#'''[[Sponsor]]'''. A stakeholder who authorizes or legitimizes the product development effort by contracting for or paying for the project.
 +
#[[File:Change-control.png|400px|thumb|right|[[Change control board]]]]'''[[Change control board]]''' ([[Change control board|CCB]]). A formally constituted group of stakeholders who is able to change [[requirement baseline]]s or, in other words, to make decisions regarding the disposition and treatment of changing requirements. The most common decisions are ''approve'' or ''reject''.
 +
#'''[[Project management office]]''' ([[PMO]]). A group or department within an [[enterprise]] that discovers, analyzes, designs, and distributes the [[enterprise knowledge]] that is related to [[project management]] in order to achieve [[economy of scale]] with regard to [[project management]]. With regard to a particular [[project]], [[PMO]] can play consulting, directing, and/or controlling roles.
 +
#'''[[Agile team]]'''. A [[workteam]] that is responsible for committing to work, delivering and driving the product forward from a tactical perspective in terms of [[Agile methodology]]. Usually, an [[Agile team]] is a small, high-functioning group of five to nine people who collaboratively work together to complete an iteration or project. The team has the necessary skills and competencies to work on the project. Scrum teams are cross-functional; Kanban teams can either be cross-functional or specialists. Scrum teams lack any roles. Kanban teams usually have team leads.
 +
#*[[Agile team member]]. A member of an [[Agile team]]. Often, [[Agile team]] include engineers, architects, developers, analysts, QA experts, testers, UX designers, etc.
 +
#*[[Team lead]]. A [[team member]] who may or may not have [[authority]] over other [[team member]]s and is appointed on permanent or rotating basis to serve one or more [[management function]]s such as (1) to represent the team to the next higher reporting level, (2) to make decisions or to make decisions in the absence of a consensus, (3) resolve [[conflict]]s between [[team member]]s, and/or (4) coordinate team efforts. No [[team lead]] is appointed in [[Scrum]].
 +
#'''[[Scrum role]]'''. One of the following: [[product owner]], [[Scrum master]], [[Agile team member]].
 +
#*[[Scrum master]]. A facilitator for the team and [[product owner]]. Rather than manage the team, the [[Scrum master]] works to assist both the team and [[product owner]] in the following ways: (1) Remove the barriers between the development and the [[product owner]] so that the [[product owner]] directly drives development. (2) Teach the [[product owner]] how to maximize return on investment (ROI), and meet his/her objectives through Scrum. (3) Improve the lives of the development team by facilitating creativity and empowerment. (4) Improve the productivity of the development team in any way possible. (5) Improve the engineering practices and tools so that each increment of functionality is potentially shippable. (6) Keep information about the team's progress up to date and visible to all parties. [[Scrum master]] is often viewed as the coach for the team.
 +
#'''[[Task force]]''' (ad hoc committee). A temporary committee or team formed to tackle a specific short-term problem affecting several departments.
 +
 +
===Institutions===
 +
#[[Project Management Institute Inc]].
  
 
===Methods===
 
===Methods===
#'''[[UX project process]]'''.
+
#'''[[Development methodology]]'''.  
#*[[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.
+
#*[[Methodology]]. A set of processes, rules, templates, and working methods that prescribe how [[business analysis]], solution development and implementation is performed in a particular context.
#*[[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.
+
#*[[Plan-driven methodology]]. Any methodology that emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. Plan-driven methodologies emphasize the reduction of risk and control over outcomes over the rapid delivery of a solution.
#*[[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]].
+
#*[[Change-driven methodology]]. A methodology that focuses on rapid delivery of solution capabilities in an incremental fashion and direct involvement of stakeholders to gather feedback on the solution's performance.
#*[[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.
+
#'''[[Agile methodology]]''' (or [[Agile development methodology]]). The project management approach of developing increments of [[prototype]]s and, eventually, the [[deliverable]] in frequent iterations based on evolving requirements. In other words, the [[Agile methodology]] is characterized by the division of [[job task]]s into short phases of work and frequent reassessment and adaptation of initial objectives. Instead of well-defined [[project]]s in the [[Waterfall model]], the [[Agile methodology|Agile one]] suggests a series of development sprints. This ''methodology'' emphasizes clearly-defined development rules with regard to both development and continuous feedback to refine the [[product scope]] rather than a predefined development process. This feature makes the ''methodology'' instrumental in those development that are inherently unpredictable. The [[Agile Manifesto]] was the initial public declaration for [[Agile methodology]] related to software. Its authors believed that they found "better ways of developing software by doing it and helping others do it."
#*[[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.
+
#*[[Agile]]. (1) Able to move quickly and easily and/or (2) [[Agile methodology]].
#'''[[Why-What-How sequence]]'''.
+
#*[[Scrum]]. The [[Agile methodology]] that features (a) a [[self-directed team]] with no specified [[project manager]] and no [[manager]]s at all, (b) a high level of communication between team members especially through daily meetings called [[standup]]s, and (c) a [[product owner]] who is responsible for continuous feeding [[job task]]s to the team. In [[Scrum]], iterations are called sprints and are assigned a fixed length—sprints typically last one to two weeks, but can last as long a month.  
 +
#*[[Lean Agile methodology]]. An example of lightweight Agile methodology applied to project development. Lean Software Development combines the Lean manufacturing approach pioneered by Toyota in the 1950s (also known as just-in-time production) and Lean IT principles, and applies them to software. LSD places a strong emphasis on people and effective communication. LSD is defined by seven principles: (1) Eliminate waste, (2) Create knowledge, (3) Build quality in, (4) Defer commitment, (5) Optimize the whole, (6) Deliver fast, (7) Respect people
 +
#*[[Lean UX]]. Inspired by Lean and [[Agile methodology|Agile methodologi]]es, Lean UX speeds up the UX process by putting less emphasis on deliverables and greater focus on the actual experience being designed.
 +
#*[[Test-driven development]] (TDD). The practice of designing and building tests for functional, working code, and then building code that will pass those tests.
 +
#'''[[Kanban]]'''. (1) A highly visual framework that falls under the Agile umbrella. The Kanban process uses continuous work flow rather than fixed iterations to produce shippable deliverables. When applied over an existing process, Kanban encourages small, incremental changes to the current process and does not require a specific set up or procedure. Kanban focuses on completing entire projects rather than [[sprint]]s; (2) A communication system that controls the flow of the shop, and synchronizes the level of production to customer demand, and normally uses standardized quantities and movement tickets which travel with the production pieces from operation station to operation station.
 +
#'''[[Change-promoting technique]]'''.
 +
#*[[Change education]].
 +
#*[[Change communication]].
 +
#*[[Change participation]].
 +
#*[[Change-support building]].
 +
#*[[Change-commitment acquiring]].
 +
#*[[Change-promoting relationship]].
 +
#*[[Change manipulation]].
 +
#*[[Change cooptation]].
 +
#*[[Change-agent development]].
 +
#*[[Change coercion]].
 +
#[[File:Status-quo.png|400px|thumb|right|[[Change-support analysis]]]]'''[[Change-support analysis]]'''. An evaluation of the stakeholder support of the  and, vice versa, the resistance to this [[proposed change|change]].
 +
#*[[Status quo]]. A Latin phrase meaning the existing state of affairs.
 +
#*[[Restraining force]].  A force that hinders movement from the existing equilibrium ([[Kurt Lewin]]).
 +
#*[[Driving force]]. A force that directs behavior away from status quo ([[Kurt Lewin]]).
 +
 
 +
===Instruments===
 +
#'''[[Project management system]]'''. A class of computer applications specifically designed to aid with planning and controlling project costs and schedules.
 +
#*[[Redmine]].
 +
#'''[[PMBOK Guide|PMBOK® Guide]]''' (its formal title is [[A Guide to Project Management Body of Knowledge]]; also known as [[Project Management Body of Knowledge]]). An inclusive term that [[Project Management Institute]] uses to describe its sum of knowledge within the profession of [[project management]]. As with other professions — such as law, medicine, and accounting — the body of knowledge rests with the practitioners and academics that apply and advance it. The [[PMBOK Guide|PMBOK® Guide]] is designed to include proven, traditional practices that are widely applied, as well as innovative and advanced ones that have seen more limited use.
 +
#'''[[Why-What-How model]]'''.
 
#*[[The Why]]. The statement for [[need]] or "why" the customer(s) want/think/need [[The What]], possibly, in [[The How]] way.
 
#*[[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 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]].
+
#*[[The How]]. The statement for tactic or "how" to accomplish [[The What]].<blockquote><table class="wikitable" width=100% style="text-align:center;"><tr><th>[[DREPD]]</th><th>[[Why-What-How model|Why&#8209;What&#8209;How]]</th><th>[[Waterfall model|Original&nbsp;waterfall]]</th><th>[[UX waterfall model|UX&nbsp;waterfall]]</th><th>[[Waterfall model|Detailed&nbsp;waterfall]]</th></tr><tr><td rowspan="2">[[Enterprise discovery|'''D'''iscover]]</td><td rowspan="3">[[The Why]]</td><td rowspan="2">[[Requirement]]s</td><td>[[UX strategy|Strategy]]</td><td>[[Conception]]</td></tr><tr><td>[[UX research|Research]]</td><td>[[Initiation]]</td></tr><tr><td>[[Enterprise research|'''R'''esearch]]</td><td>[[Analysis]]</td><td>[[UX analysis|Analysis]]</td><td>[[Analysis]]</td></tr><tr><td>[[Enterprise envisioning|'''E'''nvision]]</td><td>[[The What]]</td><td>[[Design]]</td><td>[[UX design|Design]]</td><td>[[Design]]</td></tr><tr><td>[[Enterprise planning|'''P'''lan]]</td><td rowspan="2">[[The How]]</td><td>[[Development]]</td><td>[[UX production|Production]]</td><td>[[Construction]]</td></tr><tr><td>''A&nbsp;new&nbsp;cycle''</td><td>[[Testing]], [[Operations]]</td><td>[[UX testing|Testing]]</td><td>[[Testing]], [[Verification]], [[Deployment]], [[Validation]], [[Maintenance]]</td></tr></table></blockquote>
 
+
#'''[[Waterfall model]]'''. A sequential design process where progress is seen as flowing steadily downwards through the phases. These ''phases'' vary from one model to another:<blockquote><table class="wikitable" width=100% style="text-align:center;"><tr><th rowspan="3">[[Waterfall model]]</th><td>'''Initial''' (by Winston W. Royce)</td><td colspan="2">'''Requirements''' (system and software), captured in a product requirements document</td><td>'''Analysis''', resulting in models, schema, and business rules</td><td>'''Design''', resulting in the software architecture</td><td>'''Coding''': the development, proving, and integration of software</td><td>'''Testing''', resulting in the systematic discovery</td><td colspan="3">Debugging of defects and '''operations''': the installation, migration, support, and maintenance of complete systems</td></tr><tr><td>'''DOD'''-STD-2167A</td><td colspan="3">'''Preliminary''' Design</td><td>Detailed '''Design'''</td><td>'''Coding'''</td><td>Unit '''Testing'''</td><td colspan="3">'''Integration''' and further testing</td></tr><tr><td>'''Classic'''</td><td>'''Conception'''</td><td>'''Initiation'''</td><td>'''Analysis'''</td><td>'''Design'''</td><td>'''Construction'''</td><td>'''Testing'''</td><td colspan="3">'''Deployment''' and maintenance</td></tr><tr><td rowspan="2" style="background-color:#fff;">'''[[DREPD]]'''</td><td style="background-color:#fff;">[[Deductive DREPD|Deductive&nbsp;DREPD]]</td><th colspan="2">[[Enterprise discovery|'''D'''iscover]]</th><th>[[Enterprise research|'''R'''esearch]]</th><th>[[Enterprise envisioning|'''E'''nvision]]</th><th>[[Enterprise planning|'''P'''lan]]</th><td colspan="4" style="background-color:#fff;">&nbsp;</td></tr><tr><td style="background-color:#fff;">[[Inductive DREPD|Inductive&nbsp;DREPD]]</td><td colspan="5" style="background-color:#fff;">&nbsp;</td><th>[[Enterprise discovery|'''D'''iscover]]</th><th>[[Enterprise research|'''R'''esearch]]</th><th>[[Enterprise envisioning|'''E'''nvision]]</th><th>[[Enterprise planning|'''P'''lan]]</th></tr></table></blockquote>[[File:Waterfall.png|400px|thumb|right|[[Waterfall model]]]]
===Instruments===
+
#'''[[UX waterfall model]]'''.
#'''[[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.  
+
#*[[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.
#*[[Sprint retrospective]]. A session where the Team and Scrum Master reflect on the process and make commitments to improve.
+
#*[[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]].
 +
#*[[UX 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.
 +
#*[[UX 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.
 +
#'''[[Change implementation model]]'''. A model of a pattern that leads to successful change implementation that has been developed by John Kotter, who was a professor at Harvard Business School and world-renowned change expert.<blockquote><table class="wikitable" width=100% style="text-align:center;"><tr><th>Step</th><td>Objective</td><th>Suggested actions</th></tr><tr><td>1</td><th>Sense of urgency</th><td style="text-align:left;"><ul><li>Consider possible [[change agent]]s and resisting forces.</li><li>Create a compelling reason for why change is needed.</li><li>Communicate the reason to the entire enterprise or potential [[change agent]]s.</li><li></li></ul></td></tr><tr><td>2</td><th>Coalition</th><td style="text-align:left;"><ul><li>Form a coalition with enough power to lead the change.</li></ul></td></tr><tr><td>3</td><th>Vision</th><td style="text-align:left;"><ul><li>Using the created coalition, formulate a new vision to direct change and strategies for achieving the vision.</li></ul></td></tr><tr><td>4</td><th>Official announcement</th><td style="text-align:left;"><ul><li>Make the vision official.</li><li>Communicate both the vision and, possibly, its reasoning and achieving strategies.</li><li>Enlist a volunteer army.</li></ul></td></tr><tr><td>5</td><th>Coalition empowerment</th><td style="text-align:left;"><ul><li>Empower others to act on the vision by removing barriers to change and encouraging risk taking and creative problem solving.</li></ul></td></tr><tr><td>6</td><th>First results</th><td style="text-align:left;"><ul><li>Plan for, create, and reward short-term "wins: that move the enterprise toward the new vision.</li></ul></td></tr><tr><td>7</td><th>Meeting challenges</th><td style="text-align:left;"><ul><li>Consolidate improvements.</li><li>Reassess changes.</li><li>Make necessary adjustments in the new programs.</li><li>Sustain acceleration.</li></ul></td></tr><tr><td>8</td><th>Change&nbsp;institutionalization</th><td style="text-align:left;"><ul><li>Reinforce the changes by demonstrating the relationship between new behaviors and enterprise success.</li></ul></td></tr></table></blockquote>
 +
#[[File:Change-model.png|400px|thumb|right|[[Change process model]]]]'''[[Change process model]]'''. A [[model]] designed to outline a change implementation in [[ongoing operation]]s.
 +
#'''[[Scrum meeting]]'''. One of the following: [[story time]], [[Sprint planning meeting]], [[Sprint review meeting]], [[Sprint retrospective]], [[daily standup]].
 +
#*[[Sprint planning meeting]]. A working session held before the start of each sprint to reach a mutual consensus between the [[product owner]]'s [[acceptance criteria]] and the amount of work the development team can realistically accomplish by the end of the sprint. The length of the sprint determines the length of the [[Sprint planning meeting]], with two hours being equivalent to one week of the sprint. Using this formula, the [[Sprint planning meeting]] for a two-week sprint would last about four hours, although this can vary.
 +
#*[[Daily standup]]. A brief communication and status-check session facilitated by the Scrum Master where Scrum teams share progress, report impediments, and make commitments for the current iteration or sprint. The Daily Scrum consists of a tightly focused conversation kept to a strict timeframe; the meeting is held at the same time, every day (ideally, in the morning), and in the same location. The Scrum task board serves as the focal point of the meeting. During the Daily scrum each team member answers three questions: (1) "What have I done since the last Scrum meeting? (i.e. yesterday)" (2) "What will I do before the next Scrum meeting? (i.e. today)" (3) "What prevents me from performing my work as efficiently as possible?"
 +
#*[[Story time]]. A regular work session where items on the backlog are discussed, refined and estimated and the backlog is trimmed and prioritized.
 +
#*[[Scrum of scrums]]. A meeting that is a scaling mechanism used to manage large projects involving Scrum multiple teams. A Scrum of Scrums is held to facilitate communication between teams that may have dependencies on one another. One member from each team attends the Scrum of Scrums to speak for the team—this could be the Scrum Master but may be any team member who can effectively relay information and handle questions or concerns for the team.
 +
#*[[Sprint review meeting]]. A [[meeting]] that a [[Scrum team]] holds immediately following the completion of a sprint to review and demonstrate what the team has accomplished during the sprint. This meeting is attended by the [[product owner]] or [[customer]], Scrum Master, Scrum team, and stakeholders. The [[Sprint review meeting]] is an informal meeting (no Powerpoint slides allowed). The length of the sprint determines the length of the [[Sprint review meeting]], with one hour being equivalent to one week of the sprint. Using this formula, the [[Sprint planning meeting]] for a two-week sprint would last two hours, although this can vary.
 +
#*[[Sprint retrospective]]. A [[Scrum 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.
 +
#'''[[Version control system]]'''. The system that manages [[version control]]; it controls changes to documents, files, software codes, and other collections of data.
  
 
===Results===
 
===Results===
#'''[[Project management plan]]'''.
+
#'''[[Project management plan]]'''. A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summary or detailed.
 +
#'''[[Request for change]]'''. Any request to change the [[performance measurement baseline]] or any other [[metric]] approved by a higher [[authority]]. Any scope change almost always requires an adjustment to the cost or schedule.
  
 
===Practices===
 
===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]].''
+
''[[Monitoring Quarter]] is the successor lecture. In the [[enterprise planning]] series, the next lecture is [[Operations Management Quarter]].''
  
 
==Materials==
 
==Materials==
Line 151: Line 147:
  
 
==See also==
 
==See also==
 +
 +
[[Category:Septem Artes Administrativi]][[Category:Lecture notes]]

Latest revision as of 12:55, 6 May 2023

Project Management Quarter (hereinafter, the Quarter) is a lecture introducing the learners to product management primarily through key topics related to project management. The Quarter is the last of four lectures of Business Quadrivium, which is the second of seven modules of Septem Artes Administrativi (hereinafter, the Course). The Course is designed to introduce the learners to general concepts in business administration, management, and organizational behavior.


Lecture outline

Business Modeling Quarter is the predecessor lecture. In the enterprise planning series, the previous lecture is Concept Management Quarter.

Concepts

  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 authorized and up to the project closing.
  2. Project. One or more enterprise efforts undertaken to create a unique deliverable, functional features of which are identified or can be identified before the efforts start. Any project can be viewed as a set of processes.
    • Agile project. (1) A project which project scope cannot be predicted and defined; (2) The project that is developed using an Agile methodology. An Agile project is usually completed in several iterations or development cycles. Each iteration is reviewed and critiqued by the project team, which should include representatives of the project's various stakeholders. Insights gained from the critique of an iteration are used to determine what the next step should be in the project.
    • 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 recognized start of a project.
  3. Statement of work (SOW). A formal document that either (1) defines the entire scope of the work that shall be completed in order to implement the proposed change or (2) describes deliverables to be supplied under contract.
  4. Project life cycle. A collection of generally sequential project phases whose name and number are determined by the control needs of the organization or organizations involved in the project.
    • Project phase. A collection of logically related project activities, usually culminating in the completion of a major deliverable.
    • Project schedule. The planned dates for performing activities and the planned dates for meeting milestones.
    • Program. A group of related projects managed in a coordinated way. Programs usually include an element of ongoing work.
  5. Project life-cycle phase.
  6. Iterative development. The process of breaking down projects into more manageable components known as iterations. Iterations are essential in Agile methodologies for producing a potentially shippable deliverable or product.
    • Iterate. The act of repeating a process with the aim of approaching a desired goal, target or result. Each repetition of the process is also called an iteration.
  7. Iteration. A phase of agile development in which a deliverable (or the solution overall) is progressively elaborated upon. Each iteration is a self-contained "mini-project" in which a set of activities are undertaken, resulting in the development of a subset of deliverables, a set of features, or potentially shippable deliverable. An iteration takes a fixed or timeboxed period of time, generally spanning two to four weeks. A typical Agile project consists of a series of iterations, along with a Sprint planning meeting prior to development and a Sprint retrospective at the end of each iteration. Each iteration generally contains activities such as analysis, design, development, and testing. For each iteration, the team plans its work, does the work, and checks it for quality and completeness. Iterations can occur within other iterations as well. For example, an iteration of requirements development would include elicitation, analysis, specification, and validation activities. Iterations are referred to as Sprints in Scrum.
  8. Sprint. A fixed-length time period during which a milestone is expected to be reached. Usually, one user story or product backlog item (PBI) must be transformed into a potentially shippable deliverable and ready for review. Each sprint is assigned a set amount of time to be accomplished (sometimes referred to as timebox), which could be anywhere from one week to one month, but typically lasts two weeks. In the Agile methodology, Sprints are referred as iterations.
  9. Product backlog. (1) A set of user stories, requirements or features that have been requested by the customer and identified as candidates for potential implementation, prioritized, and estimated. The product backlog is not a to-do list; rather, it is a list of all the features the customer has requested be included in the project. The requirements include both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog. During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities. A product backlog is a changing list of product requirements based on the customer's needs. The backlog is not a to-do list; rather, it is a list of all the desired features for the product. The Agile team uses the product backlog to prioritize features and understand which features to implement first.
    • Sprint backlog. A segment of product backlog items (PBIs) that the team selects to complete during a Scrum sprint. These PBIs are typically user stories taken from the product backlog.
    • Backlog grooming. The process that occurs at the end of a sprint, when the team meets to make sure the backlog is ready for the next sprint. The team may remove user stories that aren’t relevant, create new stories, reassess priority, or split user stories into smaller tasks. Backlog grooming is both an ongoing process and the name for the meeting where this action occurs (a backlog grooming meeting).
    • Product backlog item (PBI). A single element of work that exists in the product backlog. PBIs can include user stories, epics, specifications, bugs, or change requirements. The product owner of an Agile team compiles and prioritizes the product backlog, putting the most urgent or important PBIs at the top. PBIs comprise tasks that need to be completed during a Scrum sprint. A PBI must be a small enough increment of work to be completed during a single sprint. As PBIs move up to a higher priority in the product backlog, they are broken down into user stories.
  10. Velocity. A metric that specifies how much work a team is able to complete within a single, fixed-length iteration or sprint.
    • Work 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.
  11. Release. A functional product sent to customers. In other words, release is 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 market exchangeable having enough value to outweigh the cost to deploy it. A release can be either the initial build of a market exchangeable or the addition of one or more features to an existing market exchangeable. A release should take less than a year to complete, and in some cases, may only take three months.
    • Beta launch. The limited launch of a software product with the goal of finding bugs before final launch.
    • Incremental delivery. Creating working software in multiple releases so the entire product is delivered in portions over time.
    • 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.
    • Deployment. Introduction of a new activity, procedure, or program to an organization.
  12. Change management. (1) The management of change and development within an enterprise; (2) The controlled identification and implementation of required changes within a computer system; (3) Change-control management.
  13. Impediment. Any hindrance, obstruction, and/or 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.
    • Impediment backlog. A visible or nonvisible list of impediments in a priority order according to how seriously they are blocking the team from productivity.
    • 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.
  14. Change impediment. An impediment in implementing a change.
  15. Configuration management. Enterprise efforts undertaken in order to establish and further manage consistency of a product's or system's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
    • Version control. The task of organizing a system or product containing many versions.
    • Continuous integration (CI). A software engineering practice that involves continual integration of new development code into the existing codebase.
  16. Change resistance source. A cause of one's resistance to change.
    CategoryChange resistance source
    Individual's change-resistance source
    Enterprise change-resistance source
  17. Change-control management. Practice and a set of concepts based on that practice of change control.

Roles

  1. Project manager. The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.
  2. Idea champion. An individual who takes on a particular change and actively and enthusiastically promote the change idea, build support, overcome resistance, and ensure that the change is implemented.
  3. Change agent. An individual who acts as a catalyst and assumes the responsibility for supporting proposed change implementation.
  4. Developer. Developers are responsible for the construction of software applications. Areas of expertise include development languages, development practices and application components.
  5. Sponsor. A stakeholder who authorizes or legitimizes the product development effort by contracting for or paying for the project.
  6. Change control board (CCB). A formally constituted group of stakeholders who is able to change requirement baselines or, in other words, to make decisions regarding the disposition and treatment of changing requirements. The most common decisions are approve or reject.
  7. Project management office (PMO). A group or department within an enterprise that discovers, analyzes, designs, and distributes the enterprise knowledge that is related to project management in order to achieve economy of scale with regard to project management. With regard to a particular project, PMO can play consulting, directing, and/or controlling roles.
  8. Agile team. A workteam that is responsible for committing to work, delivering and driving the product forward from a tactical perspective in terms of Agile methodology. Usually, an Agile team is a small, high-functioning group of five to nine people who collaboratively work together to complete an iteration or project. The team has the necessary skills and competencies to work on the project. Scrum teams are cross-functional; Kanban teams can either be cross-functional or specialists. Scrum teams lack any roles. Kanban teams usually have team leads.
  9. Scrum role. One of the following: product owner, Scrum master, Agile team member.
    • Scrum master. A facilitator for the team and product owner. Rather than manage the team, the Scrum master works to assist both the team and product owner in the following ways: (1) Remove the barriers between the development and the product owner so that the product owner directly drives development. (2) Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum. (3) Improve the lives of the development team by facilitating creativity and empowerment. (4) Improve the productivity of the development team in any way possible. (5) Improve the engineering practices and tools so that each increment of functionality is potentially shippable. (6) Keep information about the team's progress up to date and visible to all parties. Scrum master is often viewed as the coach for the team.
  10. Task force (ad hoc committee). A temporary committee or team formed to tackle a specific short-term problem affecting several departments.

Institutions

  1. Project Management Institute Inc.

Methods

  1. Development methodology.
    • Methodology. A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context.
    • Plan-driven methodology. Any methodology that emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. Plan-driven methodologies emphasize the reduction of risk and control over outcomes over the rapid delivery of a solution.
    • Change-driven methodology. A methodology that focuses on rapid delivery of solution capabilities in an incremental fashion and direct involvement of stakeholders to gather feedback on the solution's performance.
  2. Agile methodology (or Agile development methodology). The project management approach of developing increments of prototypes and, eventually, the deliverable in frequent iterations based on evolving requirements. In other words, the Agile methodology is characterized by the division of job tasks into short phases of work and frequent reassessment and adaptation of initial objectives. Instead of well-defined projects in the Waterfall model, the Agile one suggests a series of development sprints. This methodology emphasizes clearly-defined development rules with regard to both development and continuous feedback to refine the product scope rather than a predefined development process. This feature makes the methodology instrumental in those development that are inherently unpredictable. The Agile Manifesto was the initial public declaration for Agile methodology related to software. Its authors believed that they found "better ways of developing software by doing it and helping others do it."
    • Agile. (1) Able to move quickly and easily and/or (2) Agile methodology.
    • Scrum. The Agile methodology that features (a) a self-directed team with no specified project manager and no managers at all, (b) a high level of communication between team members especially through daily meetings called standups, and (c) a product owner who is responsible for continuous feeding job tasks to the team. In Scrum, iterations are called sprints and are assigned a fixed length—sprints typically last one to two weeks, but can last as long a month.
    • Lean Agile methodology. An example of lightweight Agile methodology applied to project development. Lean Software Development combines the Lean manufacturing approach pioneered by Toyota in the 1950s (also known as just-in-time production) and Lean IT principles, and applies them to software. LSD places a strong emphasis on people and effective communication. LSD is defined by seven principles: (1) Eliminate waste, (2) Create knowledge, (3) Build quality in, (4) Defer commitment, (5) Optimize the whole, (6) Deliver fast, (7) Respect people
    • Lean UX. Inspired by Lean and Agile methodologies, Lean UX speeds up the UX process by putting less emphasis on deliverables and greater focus on the actual experience being designed.
    • Test-driven development (TDD). The practice of designing and building tests for functional, working code, and then building code that will pass those tests.
  3. Kanban. (1) A highly visual framework that falls under the Agile umbrella. The Kanban process uses continuous work flow rather than fixed iterations to produce shippable deliverables. When applied over an existing process, Kanban encourages small, incremental changes to the current process and does not require a specific set up or procedure. Kanban focuses on completing entire projects rather than sprints; (2) A communication system that controls the flow of the shop, and synchronizes the level of production to customer demand, and normally uses standardized quantities and movement tickets which travel with the production pieces from operation station to operation station.
  4. Change-promoting technique.
  5. Change-support analysis. An evaluation of the stakeholder support of the and, vice versa, the resistance to this change.

Instruments

  1. Project management system. A class of computer applications specifically designed to aid with planning and controlling project costs and schedules.
  2. PMBOK® Guide (its formal title is A Guide to Project Management Body of Knowledge; also known as Project Management Body of Knowledge). An inclusive term that Project Management Institute uses to describe its sum of knowledge within the profession of project management. As with other professions — such as law, medicine, and accounting — the body of knowledge rests with the practitioners and academics that apply and advance it. The PMBOK® Guide is designed to include proven, traditional practices that are widely applied, as well as innovative and advanced ones that have seen more limited use.
  3. Why-What-How model.
  4. Waterfall model. A sequential design process where progress is seen as flowing steadily downwards through the phases. These phases vary from one model to another:
    Waterfall modelInitial (by Winston W. Royce)Requirements (system and software), captured in a product requirements documentAnalysis, resulting in models, schema, and business rulesDesign, resulting in the software architectureCoding: the development, proving, and integration of softwareTesting, resulting in the systematic discoveryDebugging of defects and operations: the installation, migration, support, and maintenance of complete systems
    DOD-STD-2167APreliminary DesignDetailed DesignCodingUnit TestingIntegration and further testing
    ClassicConceptionInitiationAnalysisDesignConstructionTestingDeployment and maintenance
    DREPDDeductive DREPDDiscoverResearchEnvisionPlan 
    Inductive DREPD DiscoverResearchEnvisionPlan
  5. UX waterfall model.
    • 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.
    • UX 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.
    • UX 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.
  6. Change implementation model. A model of a pattern that leads to successful change implementation that has been developed by John Kotter, who was a professor at Harvard Business School and world-renowned change expert.
    StepObjectiveSuggested actions
    1Sense of urgency
    • Consider possible change agents and resisting forces.
    • Create a compelling reason for why change is needed.
    • Communicate the reason to the entire enterprise or potential change agents.
    2Coalition
    • Form a coalition with enough power to lead the change.
    3Vision
    • Using the created coalition, formulate a new vision to direct change and strategies for achieving the vision.
    4Official announcement
    • Make the vision official.
    • Communicate both the vision and, possibly, its reasoning and achieving strategies.
    • Enlist a volunteer army.
    5Coalition empowerment
    • Empower others to act on the vision by removing barriers to change and encouraging risk taking and creative problem solving.
    6First results
    • Plan for, create, and reward short-term "wins: that move the enterprise toward the new vision.
    7Meeting challenges
    • Consolidate improvements.
    • Reassess changes.
    • Make necessary adjustments in the new programs.
    • Sustain acceleration.
    8Change institutionalization
    • Reinforce the changes by demonstrating the relationship between new behaviors and enterprise success.
  7. Change process model. A model designed to outline a change implementation in ongoing operations.
  8. Scrum meeting. One of the following: story time, Sprint planning meeting, Sprint review meeting, Sprint retrospective, daily standup.
    • Sprint planning meeting. A working session held before the start of each sprint to reach a mutual consensus between the product owner's acceptance criteria and the amount of work the development team can realistically accomplish by the end of the sprint. The length of the sprint determines the length of the Sprint planning meeting, with two hours being equivalent to one week of the sprint. Using this formula, the Sprint planning meeting for a two-week sprint would last about four hours, although this can vary.
    • Daily standup. A brief communication and status-check session facilitated by the Scrum Master where Scrum teams share progress, report impediments, and make commitments for the current iteration or sprint. The Daily Scrum consists of a tightly focused conversation kept to a strict timeframe; the meeting is held at the same time, every day (ideally, in the morning), and in the same location. The Scrum task board serves as the focal point of the meeting. During the Daily scrum each team member answers three questions: (1) "What have I done since the last Scrum meeting? (i.e. yesterday)" (2) "What will I do before the next Scrum meeting? (i.e. today)" (3) "What prevents me from performing my work as efficiently as possible?"
    • Story time. A regular work session where items on the backlog are discussed, refined and estimated and the backlog is trimmed and prioritized.
    • Scrum of scrums. A meeting that is a scaling mechanism used to manage large projects involving Scrum multiple teams. A Scrum of Scrums is held to facilitate communication between teams that may have dependencies on one another. One member from each team attends the Scrum of Scrums to speak for the team—this could be the Scrum Master but may be any team member who can effectively relay information and handle questions or concerns for the team.
    • Sprint review meeting. A meeting that a Scrum team holds immediately following the completion of a sprint to review and demonstrate what the team has accomplished during the sprint. This meeting is attended by the product owner or customer, Scrum Master, Scrum team, and stakeholders. The Sprint review meeting is an informal meeting (no Powerpoint slides allowed). The length of the sprint determines the length of the Sprint review meeting, with one hour being equivalent to one week of the sprint. Using this formula, the Sprint planning meeting for a two-week sprint would last two hours, although this can vary.
    • Sprint retrospective. A Scrum 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.
  9. Version control system. The system that manages version control; it controls changes to documents, files, software codes, and other collections of data.

Results

  1. Project management plan. A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summary or detailed.
  2. Request for change. Any request to change the performance measurement baseline or any other metric approved by a higher authority. Any scope change almost always requires an adjustment to the cost or schedule.

Practices

Monitoring Quarter is the successor lecture. In the enterprise planning series, the next lecture is Operations Management Quarter.

Materials

Recorded audio

Recorded video

Live sessions

Texts and graphics

See also