Projects are unique initiatives that have a specific scope, that must be done in a limited time, that have a tight budget, and in most cases they also compete with many other equally valuable projects. Somehow we need to develop techniques to manage many projects run by many independent Project Managers as if these projects are part of a larger plan. We have to face up to the fact that we may be referring to teams, and organizations, when the reality is that there is no real team spirit that permeates throughout the organization. This can have serious consequences for I.T. projects that may be setup in competition with each other, by design or by default, and that cannot possibly all use the same limited resources to get to end of job. We have addressed problems like this in the past.

For the most part the "art" of Project Management is focused on single projects, whether we consider the more popular tools, the generally published techniques, or the Project Management Body Of Knowledge as defined by the Project Management Institute. This focus has produced an enormous body of reference materials on how to make projects work one way or another, and most project management training produces capable individuals that know how to use these tools and techniques. It is what they do not know that comes back to haunt projects. Often what they do not know is something as basic as the context of the project, and how their plans ought to fit the larger context in order to make these plans feasible. There is very little emphasis on tools or techniques, or even any general body of knowledge for that matter, to deal with the core problems that plague many projects.

This does not stop many Project Managers from boldly going where fools nor angels dare to dwell, in the quest of finally reaching the pot of gold at the foot of the rainbow. If we cannot be efficient, maybe we can be cheap, maybe we can get offshore developers to waste money at a fraction of the burn rate at which we usually waste the potential of local resources. The bottom line is that this only creates the appearance of fiscal control, because offshore resources are even less able to see how their work fits into the big picture, and reaching that elusive perfect end-product becomes harder to more barriers you introduce to stop people from communicating the big picture requirements. Perhaps if we can master the big picture management there are opportunities for segmenting the overall needs so that you can parcel things into small, manageable projects that clearly provide building blocks towards creating and maintaining that big picture. That is the first step to a Project Portfolio.

Many companies tend to tie the approval of projects in with their annual budget cycle, which seems like a reasonable thing to do at first. When you pay more attention to the details, you can see what happens if during a typical Project Life Cycle the emphasis is on the need for specific types of resources. The result is resource bubbles, first for analysts, then for designers, then for developers, then for testers, and then for implementers. It is easy to jump to the conclusion that people must be inefficient when you apparently have far more resources than you actually use on your projects. However, if you focus your needs on a small portion of the workforce at different times and then diminish your needs for other resources during those same times a large part of your workforce will be idle or underemployed for at least part of the time. You need to establish an approach that minimizes the underutilization of people by spreading out the work. That is the second step to a Project Portfolio.

We need a General Projects Portfolio...

Project Management takes on a new dimension when you incorporate the competing needs of many different projects. Larger companies tend to migrate towards a Project Management Office (PMO) that oversees the coordination of projects so that there is a more efficient use of resources. Smaller companies can achieve the same results by means of implementing general processes for managing resource conflicts between projects.

PM4HIRE.COM looks at projects as a series of phases that have independent completion dates. It is not necessary to run a project from start to finish in the shortest time in order to demonstrate competency, when in reality it may not be prudent to pursue a subsequent phase until the client is ready to proceed. The "penalty" for doing that is the need for better project documentation, to pass information from team to team if necessary, but overall this tends to be an advantage. Most projects are poorly documented, simply because in the rush to the finish some things seem to stand in the way of progress. Later becomes never when documentation has to be produced, and while the initial project may be an apparent success the penalties will be paid later when you try to improve on the project deliverables only to find that there is no documentation to fall back on. By ensuring the discipline of completing the documentation for each project phase before you consider starting the next phase you can avoid this problem.

We also think that it should be possible for later phases to be managed by different Project Managers, again not a problem if the PMLC methodology is properly established and implemented, and if the documentation required at the completion of each phase is delivered in accordance with the methodology standards. We have regularly focused on the requirements phases of projects, then split projects into legacy enhancement portions and GUI front-end portions and server portions, each handed over as separate (sub-)projects to different PM's until the results could be integrated and tested. This way each part can be managed by someone well versed in that type of environment, which leads to superior results. While it may seem that this would take longer, the opposite can be true if you can have different teams working concurrently on different aspects of a larger project context until the integration takes place. While this is not a prerequisite to establishing a projects portfolio it will make things a lot easier if you start out with a lot of flexibility in terms of how you stage the work effort for different projects.

In principle you should be able to look at each phase of a project as an independent deliverable, and to decide if and when you proceed with the next phase. Priorities change, needs change, technologies change, so why would any project be presumed to be unaffected by change when that change may well cause the project to be terminated? Let's put it another way. If every I.T. project you ever start is always carried out to completion there is something wrong: you probably don't do much strategic stuff and you likely agonize over every possible project so that you only start work if you are absolutely sure that there is no way anybody can change their mind. We are of the opinion that most projects are started to enable strategic opportunities, and that opportunities change. What we need is a tracking process that can quickly shift emphasis depending on how strategic opportunities come and go, so that resources can be allocated to achieve maximum competitive advantage. What we need is a paradigm shift with respect to how we think of projects and how we judge a Project Manager's job well done.

Implementing a Project Portfolio management system...

Project Management tends to be focused on unique initiatives with a limited budget and a limited time to finish, but in the real world companies tend to be focused on continuity. There is a potential conflict here, because we do not automatically see projects as part of a movie on the continuous evolution of a company, but rather as a series of snapshots that may be difficult to place in context without a lot of extra explanation. A project portfolio management system can be used to provide a clear context for how projects fit together.

PM4HIRE.COM has been involved in the implementation of a large commercial portfolio system such as ProSight, and in the implementation of more modest portfolio utilities and Work Management Systems (WMS). The goal in all these tools is to provide a big picture that makes sense to Executives that cannot be expected to mentally integrate the myriad of projects that a large company undertakes each year. Even if you start of with a master plan in which the major project phases of different projects are reflected as master tasks that can then be linked into a precedence structure you are making major strides at reducing conflicts between projects. You can even identify the major resource needs at a summary level to demonstrate the effects of load-leveling across projects so that for the most part resource utilization conflicts can be managed, if not prevented. Of course there will still be specialized skills involved that will always be at a premium no matter what you do, but that is no reason for not making an effort to keep these resource conflicts in check.

At any time you should be able to analyze your portfolio for consistency against strategic goals and objectives. As priorities shift, you should be able to identify those projects that are strategically aligned with the new goals. You should always have a backlog of work, related to new opportunities, and in many cases do the preliminary analysis work even if the implementation itself may be delayed. You must always be prepared for new system requirements. If you are consistently surprised by new business requirements then you are not looking ahead, or you are not sufficiently tapping the business contacts that can keep you informed of where things appear to be heading, and you clearly do not have a good handle on your development priorities. With a portfolio system you can classify projects (or associate projects with business goals) and you can be on top of what is going on when priorities change, so that the low priority projects are put on ice while resources are diverted to implement the new high priority strategic projects that add value to the business bottom-line.

Finishing a project is not winning a race...

If the implementation of projects is not properly coordinated there may be penalties paid in having teams idle waiting for the opportunity to finish a project, or finishing projects that are not fully tested in an integrated system. All kinds of hidden costs can result from not implementing projects as a part of a larger plan. While we may see projects as unique and time limited initiatives that kind of simplification can turn out to be a costly understatement.

PM4HIRE.COM expects every project to be a part of a larger series of initiatives, and we do not normally operate a project in isolation of that reality. What happens to a project run in isolation is that it becomes a highly competitive and sub-optimized work effort. Perhaps it looks good on paper to damn other projects and to get the results delivered on time and within budget, but if in doing just that you torpedo other key initiatives that the client benefits depend on you have not really delivered value. On the other hand, if you focus on getting the building blocks delivered by different projects in place in the right order you may delay (or even penalize) a selected project but the overal client benefits will be much greater. The whole idea of running projects as part of a portfolio is to achieve that greater bundle of client benefits by being able to deliver what is most urgently needed. Note that this requires a major shift in reporting and performance evaluation as well, you cannot expect any Project Managers to resolve conflicts for the benefit of clients if that results in their own performance to be downrated.

The good news is that our experience shows how relatively easy it can be to get a handle on a projects portfolio, assuming that the will exists to change the way projects are prioritized. Many companies are interested in ways to cut costs on projects without reducing productivity, which is not difficult so long as there is a lot of wasted effort caused by a lack of coordination across projects. Spare capacity should be directed at researching new ways of supporting business operations, so that there will be direct or indirect benefits to the company from developing that knowledge. We will be happy to work with you to establish a projects portfolio system that is right for you.