Project Management Quarter

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. 

   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 projects from the moment when the project manager is authorized and up to the project closing.
   • Project scope. The work that must be performed to produce a deliverable with the specified features and functions.
2. 

   Problem, solution, and project
   Project. One or more enterprise efforts undertaken to create a unique deliverable, most features of which are identified or can be identified before the efforts start. Any project can be presented 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.
   • Inception phase.
   • Elaboration phase.
   • Construction phase.
   • Transition phase.
6. 

   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.
   • 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. 

   Scrum
   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.
   • Sprint goal (aka Sprint theme). The key focus of the work for a single sprint.
9. 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.
10. 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 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.
    • 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.
11. 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.
12. 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.
13. 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.
    • Enterprise change management. Practice and a set of concepts based on that practice of preparing and supporting of enterprises, their stakeholders and technology in making enterprise change.
    • 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."
14. Change impediment. An impediment in implementing a change.
    • 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.
    • Change navigation impediment. A change impediment related to challenges to manage the change implementation over time, which is referred to as navigation.
    • Change resistance. A change impediment related to resistance originated from change resistance sources.
15. Change resistance source.

    Category	Change resistance source
    Individual change-resistance source	Habit. Personal security. Economic factor. Fear of the unknown. Selective information processing.
    Enterprise change-resistance source	Structural inertia. Limited focus of change. Group inertia. Threat to expertise. Threat to established power relationships.

16. Change-control management. Practice and a set of concepts based on that practice of change control.
    • Change control. A formal procedure used to ensure that changes to agreements and their derivatives, especially requirement baselines, 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 change requests.

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.
3. Sponsor. A stakeholder who authorizes or legitimizes the product development effort by contracting for or paying for the project.
4. 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.
5. Agile team. A work team 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 members and is appointed on permanent or rotating basis to serve one or more management functions 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 conflicts between team members, and/or (4) coordinate team efforts. No team lead is appointed in Scrum.
6. 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.
   • Product owner. A person who holds the vision for the product and is responsible for maintaining, prioritizing and updating the product backlog. In Agile methodology, the product owner has final authority representing the customer's interest in backlog prioritization and requirements questions. This person must be available to the team at any time, but especially during the Sprint planning meeting and the Sprint review meeting. Challenges of being a product owner: (1) Resisting the temptation to "manage" the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself. (2) Resisting the temptation to add more important work after a Sprint is already in progress. (3) Being willing to make hard choices during the sprint planning meeting. (4) Balancing the interests of competing stakeholders.
7. Task force (ad hoc committee). A temporary committee or team formed to tackle a specific short-term problem affecting several departments.

Methods

1. Make-or-buy decision. The act of choosing between manufacturing a product in-house or purchasing it from an external supplier.
2. 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.
3. 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 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 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.
4. 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.

Instruments

1. Project management software. A class of computer applications specifically designed to aid with planning and controlling project costs and schedules.
   • Redmine.
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.
   • 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.

     DADP	Why‑What‑How	Original waterfall	UX waterfall	Detailed waterfall
     Discover	The Why	Requirements	Strategy	Conception
     			Research	Initiation
     Analyze		Analysis	Analysis	Analysis
     Design	The What	Design	Design	Design
     Plan	The How	Development	Production	Construction
     A new cycle		Testing, Operations	Testing	Testing, Verification, Deployment, Validation, Maintenance

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 model	Initial (by Winston W. Royce)	Requirements (system and software), captured in a product requirements document		Analysis, resulting in models, schema, and business rules	Design, resulting in the software architecture	Coding: the development, proving, and integration of software	Testing, resulting in the systematic discovery	Debugging of defects and operations: the installation, migration, support, and maintenance of complete systems
   	DOD-STD-2167A	Preliminary Design			Detailed Design	Coding	Unit Testing	Integration and further testing
   	Classic	Conception	Initiation	Analysis	Design	Construction	Testing	Deployment and maintenance
   DADP	Deductive DADP	Discover		Analyze	Design	Plan
   	Inductive DADP						Discover	Analyze	Design	Plan

5. 

   Waterfall model
   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. 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.

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.

Practices

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