Technical projects have complexity, risk and expense that make them more difficult than average projects. With so much at stake, it’s important to manage a portfolio of technical projects exceptionally well. Management of the resources involved must also be top-notch.
This briefing describes best practices for managing a portfolio of technical projects and managing the resource allocation for those projects. Portfolio management is first explained; followed by a process for determining business value; then, best practices for resource allocation across the portfolio.
Portfolio Management
Every project in business is an opportunity that has value, and the specific value should be estimated for each opportunity. With the business value estimated for each project, they should be prioritized based on business value as a primary factor. What can make project portfolio management difficult is determining every project’s business value, and determining how many projects can be run simultaneously.
Table 1 shows an example of projects that are prioritized based on their value determined by a scoring system. This example has a combination of product development projects, continuous improvement initiatives, platform development projects, and technology development projects. The cut line is determined by a resource allocation plan. Only the top four priorities have their full resource needs available.
Senior leadership in an organization must understand the capacity limitations for completing multiple priorities successfully, and must not expect rapid completion below the cut line.
Scoring System for Business Value
A best practice for determining a project’s business value is to use a team scoring system. Each team member is a stakeholder with expertise and information that helps to determine business value. Team size should be five to ten key stakeholders. The same cohesive team should work together to score new project opportunities, so that the methodology can become consistent.
Using a portfolio of complex manufactured products as an example, the project scoring team members must have expertise in engineering resource allocation, development cost estimates, technical risk, manufacturing requirements, customer knowledge, and business finances.
Team members score each project opportunity across a number of relevant criteria. Determining the right criteria is the main challenge here. The criteria must be relevant to every type of project being scored (product development, continuous improvement, quality improvement, technology development, etc.).
Examples of common criteria used are:
Approximately seven criteria should be used for scoring project opportunities.
Table 2 shows an example of a scoring system applied to a project opportunity. In this example each of the scoring criteria are weighted in terms of general importance to the business.
A scoring system is better than using financial data for ranking projects for several reasons:
1. Not all project opportunities have clear financials and ROI, such as business process improvement projects, quality improvement projects, technology development projects, and organizational development projects.
2. Most projects do not have clear and accurate financials when the project is first initiated.
3. Many projects that are well underway have speculative financial data, which is unreliable.
The value of all business projects should be estimated in some tangible way before committing resources. A scoring system that accommodates all types of projects that an organization might execute determines a tangible value for each opportunity, and enables prioritization.
Sometimes when prioritizing projects based on team scores, certain projects will not seem to be prioritized correctly. When this happens, the team should discuss the team member’s scores that are out-of-line (such as team member 5 in Table 2), gain further understanding of their perspective, and make adjustments.
Resource Allocation
The goal of resource management across all projects in the portfolio is to have a pipeline of projects that flows smoothly, such that all top-priority projects have the resources needed when they are needed. All resources – people, money, equipment, facilities, and materials. The term pipeline management is sometimes used to describe this important business function. When
this function is performed well, the cut line for project prioritization can be determined because the resource plan determines the capacity for executing multiple projects simultaneously.
Allocating resources across multiple projects is difficult because it depends on each of the projects having an excellent resource plan. Projects that are just getting started typically don’t have a good plan yet. The master resource plan can’t be accurate until sufficient planning has been done for each project in the portfolio.
What complicates this further is that some project teams don’t estimate their resource needs accurately. This is usually due to inexperience or insufficient planning effort.
In order to be successful with resource management across the project portfolio, it’s important to first have exceptional resource planning at the individual project level. Just one major project that doesn’t have a reasonably accurate resource plan can make a mess of the master resource plan. Table 3 shows an example of the staffing plan for an engineering project.
This example is a two-year project planned by quarter. Generally it takes several iterations of planning by key team members to come up with a resource plan that is reasonably accurate. This is never perfect because of uncertainty in the future, but the project team should make this as accurate as possible by giving it sufficient time and effort.
A similar format can be used for planning other resources such as money, facilities, equipment, and materials. Spreadsheets or project-oriented tools can work well for planning resources at the project level, but these tools generally have major drawbacks when used for managing resources across multiple projects. Software that is designed for portfolio and pipeline management can be more effective.
PD-Trak is an example of a software tool that helps to manage a portfolio of projects and shared resources. Figure 1 shows an example of a PD-Trak planning sheet for resources across multiple projects. In this example, there is a shortage of electrical designers that must be resolved.
Multiple scenarios could be worked in PD-Trak, making adjustments to the resource pool, individual project staffing plans or the timing of projects, in order to resolve the resource shortage.
When resource allocation is resolved across all projects, the timing of every project can be planned and communicated using a centralized tool such as PD-Trak, as shown in Figure 2.
Technical project portfolio and resource/pipeline management is complicated because of the complex nature of technical work. Not many companies do it well because it requires tremendous dedication, working constantly to understand and resolve resource needs. In many organizations, pipeline management must be a full-time job, owned by either engineering management or a project management office.
Ownership of the resource/pipeline function is the most important aspect for success. It can be hard to find someone to own it with the right skills and a positive attitude about executing this very important business function.
About Auxilium
Founded in 2002 by lead consultant Gary Hinkle, Auxilium helps engineering-oriented businesses increase productivity, manage special projects, and develop talent. Call or text Gary Hinkle directly at 971-222-6234 or email: gary@auxilium-inc.com to learn more about consulting services offered by Auxilium.