Not recorded

Building the Project Firing Squad

Project Portfolio Management | By Patrick Gray | Read time minutes

Business people gathered around a table for a brainstorming meeting

Regardless of where your IT organisation has progressed in the evolution from a utility like service to a executor of business strategy, the bread and butter of most IT organisations is the successful execution of projects: non-recurring, limited duration activities designed around completing a defined task. As organisations have grown savvier about project management, successful execution is on the rise, however choosing the right projects to deliver remains a challenge for many companies.

The risks around deciding on appropriate projects are myriad, and much like those of any other large investment a corporation might make. Indecision leads to missed opportunities, or a competitor outmanoeuvring you while you sit on the sidelines analysing, pondering and pontificating. Poor decisions lead to bad investments, or an abundance of activity in one area at the expense of missed opportunities in another potentially more important area. In addition, nothing saps the morale of your people more than continuously making a decision, then revisiting and revising that decisions every week, bouncing your teams between objectives like larger and vastly more costly game of ping pong. So how does your organisation ensure it effectively and efficiently gives a potential project a yea or nay?

Know Thy Portfolio

Most investors have a defined allocation model for their investment portfolio, placing a certain percentage of their assets in emerging markets for example. An organisation needs to have a similar allocation model for their project spending, funding a certain percentage of infrastructure projects, and a certain percentage on R&D type projects for example. While perfecting this allocation model is a large piece of work in and of itself, it is critical to providing a framework for choosing projects. Without a defined allocation model and knowledge of what is in your current portfolio, your organisation is akin to the investor that picks the "flavour of the month" stock or fund based on someone else's advice. It is rare this type of investor succeeds in the long run, nor will an organisation that chooses projects based on articles in the IT rags, or what competitors are doing at that particular moment.

Once the allocation model is defined, any potential project can be analysed to determine how it fits within the model, and the allocation model serves as the basis for choosing projects. With the model in place, the following three areas will help ensure your company effectively and efficiently selects projects for execution.

Well-Defined Selection Process

No one likes a rigged or vague process, where decisions are made in a closed room with unknown criteria, and a verdict is handed down without any understanding of the process that engendered it. Rather, subject each project to a group of standard selection criteria that everyone is aware of in advance. Estimates on the project's return, cost and resource requirements are obvious criteria, as well as how the potential project fits within the organisation's current project portfolio. Assessments of the project's risk, and impacted business units are also helpful.

The goal of a well-defined selection process is not to create demands for reams of documentation, but to require certain metrics that can be used to compare different projects on the same terms. This adds some rigour to the process of building a case for a particular project, and allows for an "apples to apples" comparison among different potential projects.

Pick the Firing Squad in Advance

We've all seen the old cliché of "too many cooks in the kitchen" in action at some point in our careers, and chances are it appeared during the course of making a project-related decision. The most effective solution to this problem is limiting the number of people with a vote on a particular project, and making that group known well in advance of the actual selection or rejection of a project. You need not create a tyrannical dictatorship, and input and commentary can and should be solicited from many people within the organisation, but the final decision should fall to a small and defined group. This group should contain representatives from IT and the business, and preferably the C-level executives for all but the most mundane and routine projects.

The essence of this group is that it represents a cross-section of the corporation at large, not just IT and a few people outside IT that have a vested interest in the project under discussion. In fact, the optimal "firing squad" equally represents each business unit of the company, since any project that is selected will take resources away from other business units' potential projects. This group should be a standing body familiar with the selection process, rather than an ad-hoc committee thrown together at the last moment.

Make a Decision

When considering a potential project, the worst decision is always indecision. This may seem trite, considering there are always unknowns when deciding to move forward with a project or place it in the proverbial dustbin. Whether it is external market factors, pending strategy changes, or Nostradamus' latest predictions of an impending apocalypse, decision making in the corporate environment can be a difficult task. If your selection committee can not reach a conclusion, or hits a stalemate, the best alternative is to make a decision not to decide at this point. How is this different from indecision? Indecision is a constant revisiting of the project under consideration, marked by waffling and repeated requests for more information and time for deliberation. A vote not to decide requires documenting the mitigating factors that are making the decision difficult, noting any changes in the internal or external environment that would influence the decision one way or another, and selecting a timeframe in which to revisit the decision. Once these items have been recorded, the project is shelved and no longer discussed, only being revisited after the selected timeframe has elapsed. If none of the factors or circumstances that were documented have changed, the project is eliminated from consideration or shelved for another defined timeframe.

As your organisation perfects the art of the project firing squad, IT will grow to been seen as a reliable and fair arbitrator of projects. Guerrilla projects and "rogue" efforts by individual business units will gradually become a thing of the past, and the combined project portfolio will become greater than the sum of its constituent parts. While the hard work of successfully completing these projects still lies ahead, you have stacked the decks in the organisation's favour by selecting projects relevant to the entire company, through a transparent and efficient process.

What's Next?

You may also be interested in