Within the human body, the core muscles are those located in your torso that help keep your body stable. There is a similar set of stabilizers on a project, and that is the Core Team. According to Timothy J. Kloppenborg in Contemporary Project Management (2015), “Core team members are the small group of people who are on the project from start to finish and who jointly with the project manager make many decisions and carry out many project activities” (p. 73). Given their longevity and duration with the project, they provide invaluable insight into the origins of the project, old decisions, and continuity.
Today we delve into the realm of Associate Roles, as per the chart below. This article is the latest in a series that addresses the myriad Project Roles.
The composition of the Core Team will vary depending on the size, complexity, and needs of the project. Let’s use project budget as a proxy for all of those parameters. In the table below, I have compiled a list of roles that can be considered as part of the Core Team on an engineering project of varying size:
Note that for small- and medium-sized projects, just because I have not indicated a Risk Manager, Supply Chain Manager, or Quality Manager, that doesn’t mean those functions have no place on the project or that one or all of those areas is overlooked. It simply means that tasks associated with those positions are conducted by people associated with the projects on an as-needed basis. For example, the medium-sized project can ask for four hours of a Quality Engineer’s time. That person acts like a Subject Matter Expert (SME) in that he or she provides services to the project on an as-needed – versus full-time – basis.
Another thing to notice vis-à-vis Core Team members is that they all fall into functions that support the Project Scope, versus the Product Scope. The former refers to all work “that must be performed to deliver a product, service, or result with specified features and functions” (Kloppenborg, p. 448). In short, these are the tasks required to support the work of creating the deliverable. However, they are not the activities that directly result in the deliverable. Those are Product Scope activities. A quick example might help. The Core Team on a project to produce the latest and greatest Widget works on Project Scope activities such as creating the Integrated Master Schedule (IMS). The creation of the IMS does not mean the Widget is any closer to production. But, it does mean a SME can use it to understand the timing and budget of his or her design tasks. The Widget design should be considered Product Scope because it directly contributes to the completion of a project deliverable.
Given we’ve talked so much about SME’s in this post, let’s discuss them in more detail next time. See you then!