When two project managers (or PMs) get together to talk shop, you’ll hear an excess of geeky, unfamiliar lingo, like:
“How well is your MVP development avoiding scope creep?”
You might think the most valuable player is a creep, but no, this curious PM jargon means something completely different. Google Translate won’t help you here, but we will.
DelCor decodes the mysterious language of project management
Acceptance (aka User Acceptance)
Finishing the testing phase and officially accepting a piece of functionality as complete and meeting the goals of the project.
The agile development process breaks a project up into short iterative segments called ‘sprints.’ First, high-level system features and functions (requirements) are identified. Each set of requirements is prioritized based on need, cost to deploy, or level of effort. Each set goes through a sprint where requirements are further defined, an initial design and prototype is created, and the prototype is tested. The process repeats until the system feature set is completed and is ready for deployment. In contrast, compare agile with the waterfall methodology.
Business Analyst (BA)
This person helps an organization analyze their needs, gather requirements for projects, and develop solutions.
The project’s goal, which aligns with your organization’s mission and vision.
Requests for any changes to the project scope must go through an approval process before being integrated into the project timeline and budget.
A document, developed by the project manager in collaboration with the project team, that identifies project goals, secures stakeholder approval of those goals, establishes authority for the project manager, and defines the roles of each stakeholder. The charter is referenced throughout the project to ensure it stays on track.
Modifying a solution without having to rewrite the programming code, for example, configuring (modifying) the drop-down menus within the solution without having to call in a programmer. Compare with customization.
Something with the potential to impact the project’s timeline, budget, or scope. Constraints could be as simple as a change in the subject matter experts, or as complex as a change in the market.
Unlike configuration, customization requires the involvement of a programmer. Customization can also cause problems during software upgrades. All custom elements must be reapplied to the system to see if they still work with the upgrades. If they don’t, more development (programming) is required to resolve issues.
Refining requirements and removing non-essential work because time and/or money is running out.
A completed full or partial solution that’s ready for use or acceptance.
A task that is dependent on another to proceed. For example, requirements must be defined before development can occur; therefore, development has a dependency on requirements analysis. Dependencies can also be business processes (one must occur before another can proceed), systems (one must be integrated with another for a process to work), and even people (a task is dependent on a specific staff member).
The phase of the project where high-level requirements are identified but not necessarily solved. The solution takes shape based on further requirements analysis.
This person participates in discussions to help groups come to consensus. Usually the project manager takes on this role as they do not have a stake in the outcome. They simply manage the process of getting people to work together and find agreement.
Connecting two solutions together to share data, for example, integrating the AMS with an email marketing system.
Integration Management (project)
Coordination of all aspects of a project to ensure all project processes run smoothly. This laborious task involves many moving parts, including the coordination of resources (staff) who are pulled in many different directions.
Level of Effort (LOE)
The amount of work/cost/time required to complete the development of a functional requirement. For example, after the Rough Order of Magnitude is defined, and the client has approved a list of functionalities, the vendor will return to the table with a Level of Effort to help set the budget and timeline.
On any given day, we all find ourselves in meetings. If we were to define a meeting, it would be a gathering of only necessary individuals with a predefined and focused agenda that ends on time with goals met. (I know, I’m dreaming.) During a project, stand-up meetings are frequent occurrences. These are usually daily meetings where attendees stand up so the discussion is kept short and focused. Sometimes, multiple short, focused meetings are more productive than long, complex meetings. (I know, I’m singing to the choir.)
Minimal Viable Product (MVP)
A minimal viable product is a solution that meets only the minimal needs of the organization—other functionality will be addressed after go-live. This minimalist approach helps to condense a timeline.
The metaphorical place you ‘park’ ideas to discuss later. This is where you document things that must be done eventually but don’t have a defined due date. During meetings, you could use a flip chart to document ideas that come to light. All parking lot items are assigned a priority and can be placed into any phase of the project.
When a minimal viable product (MVP) is necessary to meet a go-live deadline, items that are not part of the MVP are often assigned to a Phase 2 deployment schedule. Phase 2 development usually kicks off near the end of the first phase so continuous development can occur. However, Phase 2 items are often re-evaluated to see whether they’re still needed.
Project Management Office (PMO)
A project management office has a lead project manager who looks out for all the projects in play to ensure the appropriate resources and time are allocated to each project. The PMO is also responsible for aligning all projects with the organization’s mission and vision.
A credential indicating someone is a ‘Project Management Professional’ because they have been thoroughly trained, tested, and certified by the Project Management Institute.
Final phase of a project when the product is accepted, lessons learned are captured, and project information is archived.
Project Manager (PM)
The project’s conductor and advocate who ensures the project team has a clear direction and the right resources for the project. The PM keeps the project moving on schedule and within budget, and facilitates decisions on changes. It’s important to note that while the vendor will have a PM on the project, the client association should also have their own PM to coordinate their project responsibilities.
This document—developed by the project manager in collaboration with the project team—guides the execution and management of a project by defining planning assumptions and decisions, as well as approved baselines for scope, cost, and schedule. The project plan can even define how the organization plans to communicate about the project, how changes will be addressed, and the roles and responsibilities of all the parties involved. This living document is maintained by the project manager and updated regularly so it remains aligned with project reality.
Documentation of all projects within an organization in progress or in the planning stage, including the project’s name, status, and relationship to the organization’s mission and vision.
RACI stands for the four levels of project responsibilities: Responsible, Accountable, Consulted, and Informed. The matrix provides a visual depiction of each person involved and their roles during different project phases or activities. In addition to this reference tool, additional value is gained from the conversations that go into developing the matrix.
A clearly defined functionality that leaves little or nothing to the imagination. For example, “the system shall enforce a unique username and password for each user to access the system.” The key to a good requirement is to not assume the requirement is understood. Document, document, document…
Requirements Analysis (RA)
A process of evaluating in detail all the functional requirements the solution must deliver in order to meet the needs of the association. The rough order of magnitude—and, later, the level of effort—come out of this process.
Rough Order of Magnitude (ROM)
Rough order of magnitude is a high-level estimate of cost by the vendor. It’s used to help the client decide whether to proceed with the requirement or functionality. Once a decision is made to proceed, the level of effort is provided.
Definition of what the project is supposed to accomplish and the budget and timeline approved to achieve those objectives.
This is a sneaky one! Scope creep occurs when new requirements or changes to existing requirements require the project to change direction. They also have the potential to increase cost and lengthen the timeline.
Subject Matter Expert (SME)
The person with the most intimate knowledge of a specific topic.
Statement of Work (SOW)
This document, developed by the vendor, describes the project’s objectives, scope, deliverables, risks, constraints, and stakeholders. It reflects the work (development) that will occur during a given phase.
An executive who champions (advocates) the project being financed, staffed, and supported. This person is the PM’s best friend!
Anyone—and we mean anyone—who will be affected by the completed solution, such as members, staff, board, etc. Identify all potential stakeholders so their needs have a chance to be reflected in requirements.
This document, developed by the project manager in collaboration with the project team, contains information about all project stakeholders.
Three factors—scope, time, cost—that must be handled effectively for the successful completion of any project. If one of these constraints changes, another must be adjusted to keep balance in the project. For example, if you add additional scope you must either add more money or time to the project.
User Acceptance Testing (UAT)
A test drive of the new technology by the organization’s staff. This is one of the most important phases of the project to ensure all components of the solution are working as expected.
Scenarios illustrating how a user (member, staff, or someone else) will interact with the product in real life. Fill in the following blanks to create a valid user story that you can use during testing: “I am a/an __________ who wants to __________ with the outcome of __________.”
The waterfall development process progresses in the traditional project order: requirements are gathered from stakeholders, the system architecture and overall plan are designed, the system is developed and integrated with other systems, testing and acceptance occurs, and, finally, the system is rolled out to users. Once you pass from one phase to the next, you don’t revisit the previous phase again, unlike the agile methodology.
A visual layout displaying how components will appear on the screen—done in black and white to ensure the end user does not focus on the visual design of the page, but only on the functionality.
There you have it: project management translated. Did we miss any?
If you want to see how some of these terms shake out in real life, download our free white paper, Requirements Analysis: The Secret to Sanity.