這篇是轉貼的文章,談的昰組織該如何篩選專案。
尤其現在是年底了,很多組織都在做明年的專案規劃。 但怎麼樣的Project Portfolio最合適呢? 一部分人會有個迷思,以為最好公司能開的案是「越多越好」。
但以我經驗而言,這未必是對的。 因為啟動超過組織能力負荷的案子數量,有可能最後全部做不出來、或都嚴重Delay、或無法照顧好每個客戶(或產品線)、或壓力太大讓人員陣亡。 最後結果往往不會比「適量」來的好。 但如何評判適量? 又如何選案? 這篇文章有些做法上的建議。 (下週有空時,我也可以分享我個人在此議題上的看法)
這篇文章的原始標題叫做 Next Year’s Portfolio。 是Abid Mustafa於11/21/2011發布在Project At Work網站上的文章。 作者Abid Mustafa是一個PMO的主管,之前他有一篇跟PMO建置相關的文章我也有分享過。
Next Year’s Portfolio
by Abid Mustafa, November 21, 2011
Every year there is a mad scramble by most companies to secure budgets internally for projects they intend to do for the following financial year. Typically, companies are flooded with requests from various departments to deliver capabilities and benefits through a variety of projects and programs. However, companies are acutely aware that there has to be a balance between the long wish list of things to do, and the organization’s actual ability to deliver them. Usually this leads to a onerous quest to estimate the number of projects and programs that can be delivered in a single year. In the absence of a workable corporate planning process (one that provides a prioritization framework to validate whether the right projects should be done or not) this becomes a daunting exercise for executives and their senior management teams.
Here are some techniques that, on their own or collectively, can assist companies to overcome this dilemma:
Establish a project filtration standard
Given the chance, business units will add anything to the company’s list of things to do. Items that would never qualify as project work are often added. Once all the business units have finished contributing, the wish list is usually very long and lacks detail. Trawling through such a list and deciphering every item is a tedious exercise. Furthermore, to discover that a significant proportion of items do not constitute project work is extremely painful, and quite frankly a waste of the company’s time!
To minimize the inclusion of non-project items and to encourage sufficient detail to reduce protracted dialogues with the business units demands a project filtration standard to be established and communicated to the relevant parties. At its simplest level, this could entail distinguishing between development work and operational work. In practice however, a more versatile standard is required to perform the filtration. This should consist of: a business case for the intended project work, its alignment with corporate strategic objectives, project size (small, medium, and large) and high-level project information (sponsorship, scope, objectives, time lines etc.).
If the filtration standard is implemented correctly, it should preclude items like “photocopier installation, exchange server memory upgrade, 10 employee desks” from appearing on the list. Additionally, short sentences to describe project work such as “ERP system is required because everyone else has one, and it will take 6 months to implement” will be actively discouraged and excluded from the list, unless sufficient detail is provided.
Impose an overall budget
Another technique that can be employed to restrain the company’s wish list is to impose an overall project budget for the company. The total budget can be divided into specific budgetary envelopes which the business units use to calculate project submissions. However, the value of the total project work submitted must not exceed the overall project budget, but individual envelopes can be exceeded. In practice, this requires strict rules to regulate negotiations between the various business units; otherwise there is a danger that whole exercise can become protracted.
A variation to this approach is to set a specific monetary threshold to admit project work into the company’s to do list. Therefore, if an item meets the threshold value, it is included on the list. Nonetheless, an overall cap on project spending is imposed to inhibit too many items from entering the list. Whilst both approaches are quick and dirty, they lack the intelligence to ascertain what really constitutes project work.
Use historical data
The first two techniques are good at restricting the company’s wish list, but are quite poor at providing an indication as to how many projects the company can actually deliver. One technique that can help in this respect is to use historical project data to determine the organization’s current ability to deliver number of projects. The accuracy of this method is greatly dependent upon the quality of the project data: if the project data is incomplete, inconsistent, or contradictory, then it may be prudent to use procurement data to calculate just how many projects started, or stopped, in a given a year.
However, even this may not be enough to provide an answer with certainty. If the quality of project data is too poor to provide a reliable figure, then benchmarking could be used to determine company’s delivery capability. However, benchmarking provides the industry figure as to what a similar size organization in a specific business area should be delivering. It is not a measure of how many projects the organization in question can deliver presently. In any case, both historical data and benchmarking can assist organizations to aim for the optimum number of projects they should deliver in a given year.
Use critical resource head count
An expedient method for fixing the number of projects is to base it on the number of critical resources used by the company to deliver project work. The critical resources can be project managers, analysts, architects, designers, testers, trainers etc. All organizations have a finite number of resources and in the current economic climate; the tendency is to do more with less. Hence, resource sharing is imperative to deliver projects. So it should be quite straightforward to come up with a reasonable figure, which all parties can concur with. For instance, if there are 15 project managers then it is reasonable to assume that they would not be able to deliver more than 20 medium-size projects.
Group projects into programs
One of the ways to do more with less is to group projects into programs and then manage the delivery to produce the requisite capabilities and benefits. The advantage of this approach is that the organization as a whole can focus on a small number of programs in a given year. However, the greatest challenge facing such an approach is the organization’s maturity to plan and effectively collaborate. Provisions are also made for unplanned projects, or programs, which can arise due to market conditions and regulatory edicts.
Consider executive threshold
Lastly, one of the biggest constraining factors is how much time executives can devote to project sponsorship. Typically, executives have their schedules full with strategic, operational, management, financial and commercial responsibilities. Finding time to sponsor projects in additions to these responsibilities is a struggle for the best of executives. Most likely, executives will not be able to commit beyond one or two major projects and programs. Therefore, using executive attention to measure the organization’s ability to deliver is an extremely useful technique.
In conclusion, a selection of any techniques listed above can be employed to calculate the organization’s ability to deliver within a defined budget. However, this is merely a temporary solution. A more permanent solution necessitates such techniques to be integrated into the company’s corporate planning process. Only then, will the company be able to accurately determine its capability to deliver a specific number of projects and programs each year.
本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。