Project management is the foundation on which successful projects are built. Effective project management includes a clear definition of project scope and decision-making authority, dividing a project into actionable tasks, assigning responsibilities to team members, timelines over which phases are to be fulfilled, and final deliverables of the project.
The following is my understanding of project management, thus it is primarily focused on physical product development. For services, software, and large civil works, modifications would likely be necessary.
Content List
Process Group Approach
A traditional and intuitive approach to project management is relying on five process groups:
- Initiation — A project statement describing purpose, deliverables, risks, approximate timeline, and resource budget are defined. Stakeholders are identified and responsibilities are assigned.
- Planning — High-level tasks are reduced to actionable work. Timeline and resource budget are refined using estimates of required time and effort. Approval to begin work is given.
- Executing — Allocated resources are processed into deliverables as described by the plan. Documentation of activity and the work process is created concurrently.
- Monitoring/Controlling — Actual status of the deliverables is measured and compared to the plan to determine project health. Corrective actions to overcome issues and adjust the pace of development are determined and implemented into execution, with large changes leading to a revised version of the plan.
- Closing — The project is formally concluded, open contracts are closed, and documentation is archived. A post-implementation review of the endeavor to draw conclusions regarding successful habits is done to inform future work.
Flowchart of the five process groups. Adapted from “Project Management Guide” (PDF). VA Office of Information and Technology. 2003. Archived from the original on January 14, 2009.
↑ Back to Contents ↑
Initiation
Properly defining and planning the goals of a project are the most undervalued aspects of project management in my opinion. There is often an urge to skip extensive planning and just jump into tackling the immediately evident tasks. This approach is a great way to exhaust resources without confidence they are being utilized well.
Scope Statements
The single most crucial element of the initiation phase are project and product scope statements. These clearly delineate what is included, and also excluded, from the project. Ideally they are supported with evidence collected from user research and testing. Scope statements are the skeleton on which more detail may follow, and are the best defense against uncontrolled scope creep.
Product
- Functional requirements
(WHAT it does, ex. “Passes rain test”)- Load bearing capacity, size
- Runtime, power draw, thermals
- Durability, Ingress Protection (IP)
- Color, shape, texture
- Non-functional requirements
(HOW it does, ex. “Usable in rainy weather”)- Scalability of design
- Ease of maintenance
- Ergonomics and portability
- Value-added features for the customer
- Target unit cost and price
- Product development milestones
Project
- Overall resource budget (time, expertise, labor, manufacturing processes, funding)
- Delegation of responsibilities across team
- Authority of stakeholders
- Specialized workers
- Supervisors
- Managers
- Executive leadership
- Vendors/suppliers
- Regulatory agencies
- End users
- Procedure for modifying project plan in future as necessary
- Project milestones
Responsibility Assignment Matrix
A developed delegation of responsibility across stakeholders may take the form of a RACI matrix (or one of its derivative versions). RACI is an acronym describing the four roles of stakeholders:
- Responsible: Who executes the actions that accomplish tasks
- Accountable: Who owns the task and is the point of contact for inquiries about it
- Consulted: Who serves as a source of expertise for a task (two-way communication)
- Informed: Who is notified of task status (one-way communication)
The matrix is typically expressed with stakeholders along the top and tasks descending on the left.The intersection of a stakeholder and task contains the appropriate role. Usually each stakeholder holds a single role, but in specialized tasks a single party may be both responsible and accountable.
↑ Back to Contents ↑
Planning
It’s obviously impossible to perfectly predict a project’s trajectory from the start, but having a plan informs how to handle the unexpected. The appropriate level of detail depends on the viewer, so filtering out or adding detail may be necessary. A well crafted document should be able meet the needs of all stakeholders responsible for development.
Gantt Charts
Gantt charts are a form of timeline, acting as a visual representation task progress. Every Gantt chart has a single critical path, the longest connected series of dependent tasks. As an example, the critical path for baking a cake could be:
Choose recipe → Obtain ingredients → Mix batter → Place into heated oven → Icing
The required ingredients aren’t known until a recipe is chosen, batter cannot be mixed until ingredients have been obtained, the cake can’t be baked until the batter is made, and icing can’t be added until the baking has finished. Tasks like heating the oven or retrieving the cake pan don’t lie on the critical path because strictly speaking they can be started anytime; they would be sub-tasks of placing into a heated oven.
↑ Back to Contents ↑
Executing
With the plan providing justification to perform it, work can begin. Based on the functional and non-functional requirements laid out in the product scope statement, aspects of the product design are determined through simulation, prototype testing, and available manufacturing processes.
Design reviews are meetings in which different groups such as designers, engineers, machinists, and quality control give feedback to inform the next iteration. They are helpful in ensuring the design does not overlook the needs of stakeholders not directly involved in design. If a certain aspect is lacking, (accommodation for wiring, ease of manufacture/assembly, external appearance, cost, etc.) a design review is a way to draw out all the details into an actionable list of necessary changes.
Documentation
Documenting the work is a crucial but under performed responsibility. Nobody is as familiar with the challenges and solutions of a task as the one addressing it, and that knowledge needs to be recorded in some persistent format accessible to the broader team. Otherwise, project stability goes into jeopardy should said team member go on vacation or otherwise be unavailable.
Approaches to documentation vary depending on the needs of the project:
Simple
- If a project:
- Is worked on at a single location
- Has few stakeholders (< 5)
- Is short in total duration (< 6 months)
- Consider:
- Log notebook kept on-site
- Whiteboard with high-level schedule
- Single digital container for all files
Advanced
- If a project:
- Is worked on by people at several locations/time zones
- Has significant quantity of stakeholders ( > 5)
- Is not short in duration (> 1 year)
- Consider:
- Team drive and an established file structure (Sharepoint, Dropbox, Google Drive, Github)
- Dedicated project management document
Regardless of the documentation method, all members should abide by a universal naming scheme. Good things to include in a document title are the project name, two to three word description of content, date of creation, and version number (if not already handled by the chosen method).
↑ Back to Contents ↑
Monitoring/Controlling
To preserve the goals of a project as defined in the initiation process, the status of tasks needs to be tracked. The aim is to assess often enough that shortcomings can be remediated timely and windfalls can be leveraged fully.
To avoid siloed information and unforeseen delays, it’s important to establish and maintain opportunities to catch others up on task status. These can be brief standing meetings (< 30 min), informal talks at someone’s desk at the start of each week, or a team message thread. If someone is new to their task, they may lack the experience to fully understand the extent of a setback. Sharing challenges with others leverages the expertise of the group, or at least redirects group resources to a more efficient use.
If a problem significantly affects the plan (such as supply chain shock or departure of team members), revisions should be made. Ideally the stakeholders required to develop alternative steps were defined in the initiation process. Once an acceptable replacement is agreed upon, the new plan should be made available in place of the prior one.
Monitoring and controlling may also include support of a project post-launch, such as revisions to user manuals.
↑ Back to Contents ↑
Closing
Once the product has launched, the project is coming to a close and any loose ends need to be tied up.
User manuals should be finalized using details from the released version of the product. The dependencies of digital design files managed through Product Life Management (PLM) software should be confirmed. Physical files and parts should be archived in storage or disposed of if unneeded to make room for the next project. Any outstanding agreements with vendors, contractors, etc. should be recognized as complete by all parties.
After wrapping up, reflecting on the project is important to appreciate the accomplishments, as well as understand what worked well and what didn’t succeed to guide future projects.
↑ Back to Contents ↑
Phase-Gate Approach
A phase-gate project management approach divides the project into sequential phases, each separated by a gate where the project is reexamined and either cleared to continue, halted, reworked, or killed. The exact number of phases differs by implementation, usually between 4 and 7. Phases function similarly to the process groups described above.
Credit to www.triskellsoftware.com
The gate committee is usually composed of upper-level stakeholders such as senior managers, business unit executives, sponsors, and the project manager. This allows for a blend of insight from those focused on project technical feasibility, company financials, market research, etc.
Conditions to pass the gates may be judged as pass/fail or using a scoring system. Some variants refer to these as “Must Meet” and “Should Meet” criteria, where Musts determine if the project is killed and Shoulds determine how much rework is necessary.
Adapted from www.smartsheet.com
Large projects often span many years, and the justification or market need that was present at the start may have evaporated during development. The reevaluation at each gate reaffirms the value of the project. This frees up resources for the projects that can make the best use of them.
If a project is ended after failing to pass a gate, there is still residual value in the work that was completed. Examination of what led to shortcomings in gate criteria can yield lessons to make future projects more robust and likely to succeed. File templates can be reused, and experience gained in getting the project to its final stage develops human capital.
↑ Back to Contents ↑