Several organizations that I have met with over the years think that, in order to start developing a portfolio of their projects, they have to purchase a large system or have experts specifically trained as portfolio managers. I find that most of these companies are trying to build the Golden Gate Bridge to cross a two-foot stream. I tell people to first take out a pencil and a piece of paper (okay, a word processing program will also work, but that's technical).
The first factor in building your project portfolio is to determine what constitutes a project for your organization. The Project Management Body of Knowledge Third Edition, published by the Project Management Institute, defines a project as:
A project is a temporary endeavor undertaken to create a unique product, service or result.
This definition can be somewhat vague in most organizations. In Higher Education, for example, this definition can be applied to each unique learning objective developed for use in the classroom. Some of these objectives can be developed in a few hours to hundreds of hours depending on the complexity of the subject matter and the media used. For the "quickie" learning objectives, it can often take more time to initiate the project process than to complete the project. This can cause problems for the person maintaining the portfolio, as projects can be removed as quickly as they were added to the list.
When working with a client or organization, I get them to try and further develop a project definition for their organization. This will help them as they go out and speak with team members to start the initial portfolio list. Some criteria that I have seen developed include:
1. The sum of work needed to complete a project is greater than 80 hours.
2. The project requires funding other than current staff time. This can include additional money needed for contractors, hardware, software, etc.
3. The project is going to need resources from more than one department in order to complete.
4. The implementation of this project has high visibility at all levels in the organization.
Once a project definition can has been finalized and approved by management, then it becomes easier to identify those projects hidden in each area. As each project is identified, an estimated completion date should be identified along with the effort required to complete the project. The portfolio manager should also make sure to capture any project that may be starting in the near future. This will help as they start to balance the portfolio and determine at what point resources may be available to take on new or additional work to complete existing projects.
Once a list has been gathered, there should be some effort made to rank the projects in order. Since resources are often limited while the customer wish list is infinite, a key to ranking a portfolio is to get the customer involved. Often, the performing organization takes on the responsibility of ranking the projects or working on a first in / first out basis. This can -and often does- lead to political battles and loss of opportunities for the organization. This is especially true for organizations that may be performing projects for a variety of customers. One suggestion is to get a steering group together of key representatives from each customer area that may submit a project. This should be someone with authority to answer for the area and can include a vice-president or director of the division.
Once the steering group is assembled, the first task is to develop a method that can be uniformly applied to any project being requested. Each member of this group should work to gather to determine the key factors in moving projects forward. This can include factors for projects related to company strategy, need of project, service life of existing systems, cost, etc. Each factor should include a scale and a score related to each. Once the scoring sheet has been finalized, then the group should rank each project that was uncovered during discovery (again, this can be done with pencil and paper, although a spreadsheet application will make adding up the scores easier).
Once each project has been given an equal hearing and ranked using the same methodology, the projects should be listed from highest to lowest. Once listed, the performing organization should go in and draw a line at the point of the list where they can say with confidence can be completed in a reasonable amount of time. Those projects above the line can be further classified into high and medium priority. A high priority project means that every effort will be given to meet the estimated timeline while a medium priority project may slip some depending on higher priority projects. Those projects below the line are designated as low priority or "on the list."
A process should be defined so that any new project being requested also goes through this process. New projects should be moved into the project list. This means that projects may move down the list as new projects are added or up the list as projects are completed. This will help with setting customer expectations on when projects will be completed. This will also assist the performing organization's employees to know on what projects they should be working. If there is a conflict for a resource, higher priority projects should win out. If customers don't like it, then they can work with the steering group to have their projects reclassified higher.
Once you have listed and ranked all of the projects, then you can focus on applications and tools to help you maintain the list. The good thing about building the list first is now you can better determine if you need a product to manage 10 or 100 projects. You can also look at the complexity of the projects and factor that into your criteria in selecting a tool. Of course, you'll want to find something more high tech than a pencil and paper.
__________________
Interested in sharing your PPM & IT governance insights with others in Higher Ed?
Email Jennifer at jhuber@teamdynamixhe.com to learn more.