Different project managers will categorize project resources differently. The hive mind of wikipedia states, “They can be people, equipment, facilities, funding, or anything else capable of definition (usually other than labour) required for the completion of a project activity.” The PMBOK’s glossary definition defines resource as, “Skilled human resources (specific disciplines either individually or in crews or teams), equipment, services, commodities, material, budgets, or funds.”* The labels for these categories will also change based upon industry and organization communication standards.
In reality the categories different project managers will use depends upon their expert judgement, experience in the field, and the type of project they’re managing. In my opinion the type of project appears to be the #1 driver for resources identification and integration. You can’t build a certain project without the materials to do so. The second driver (also in my opinion) appears to be organizational norms. Since there are different methods to accomplishing a task there are also different resources used to do it. While it is possible to communicate and coordinate activities using regular postal communications, most industries communicate using electronic technologies. These technologies, computers, phones etc, are resources necessary to project implementation and success.
Many of these resources are determined in the planning process group while some are identified during the execution phase as changes occur during project implementation. These resources can be managed within functional areas as part of a weak matrix organization, or they can be managed by the project manager in a strong matrix organization. Overlaying the WBS with a resource calendar is one method to identify resource availability and implementation over top of required work to be performed.
As I’m adjusting to new projects at work one of the things I’ve become tremendously aware of is the resource of time and how it affects cost and one’s ability to do quality control. Since many of our projects can be considered iterative in nature the technique of capturing lessons learned and taking the time to apply them is significant. Just today we did a small project and captured insights that will allow us to perform better for the next iteration. Capturing the insights was only part of the task of project closure. The other part is taking the time to address the identified issues with each stakeholder to synchronize project execution on the next iteration. Tomorrow if I give my guys the next task to perform then we’ll be cutting ourselves short on building from the hard lessons learned today.