Project Management Quarter
Project Management Quarter (hereinafter, the Quarter) is a lecture introducing the learners to product implementations primarily through key topics related to project management. The Quarter is the last of four lectures of Product 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.
Contents
Lecture outline
Business Modeling Quarter is the predecessor lecture. In the enterprise implementation series, the previous lecture is Iterative Development Quarter.
Concepts
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Specific plan. A plan that is clearly defined and leaves no room for interpretation.
- Standing plan. An ongoing plan that provides guidance for activities performed repeatedly.
- Short-term plan. A plan covering one year or less.
- Single-use plan. A one-time plan specifically designed to meet the needs of a unique situation.
- Directional plan. A plan that is flexible and sets out general guidelines.
- Formal planning department. A group of planning specialists whose sole responsibility is helping to write organizational plans.
- Long-term plan. A plan with a time frame beyond three years.
- 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.
- 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.
- Procurement plan.
- Commercial-off-the-shelf software (COTS). Software developed and sold for a particular market.
- Make or buy (or build vs buy). The act of choosing between manufacturing a product in-house or purchasing it from an external supplier.
- Total cost of ownership.
- 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.
- 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.
- Risk management. A process of identifying what can go wrong and making plans that will enable a system to achieve its goals.
- Risk response plan. A document detailing identified risks, including description, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status. The proposed responses may utilize risk-response techniques such as avoidance, avoidance, avoidance, and acceptance that are designed to enhance opportunities and reduce threats to the project's objectives. The tools include .
- Contingency planning. The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.
- Workaround. A response to a negative risk event. Distinguished from contingency plan in that a workaround is not planned in advance of the occurrence of the risk event.
- 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.
- 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.
- 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.
- Requirements management. The activities that control requirements development, including requirements change control, requirements attributes definition, and requirements traceability.
- Requirements risk mitigation strategy. An analysis of requirements-related risks that ranks risks and identifies actions to avoid or minimize those risks.
Roles
- Project manager. The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.
- 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.
- 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.
Methods
- Make-or-buy decision. The act of choosing between manufacturing a product in-house or purchasing it from an external supplier.
Instruments
- Project management software. A class of computer applications specifically designed to aid with planning and controlling project costs and schedules.
- 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.
- 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.
- 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:
Unit Testing
Waterfall model Initial (by Winston W. Royce) System and software requirements: 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: the systematic discovery Debugging of defects Operations: the installation, migration, support, and maintenance of complete systems DOD-STD-2167A Preliminary Design Detailed Design Coding Integration Testing Classic Conception Initiation Analysis Design Construction Testing Implementation (deployment) Maintenance DADI one cycle Discover Analysis Design Implementation one cycle Discover Analysis Design Implementation - 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.
Results
- 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 implementation series, the next lecture is Operations Management Quarter.
