Print this page
Monday, 31 August 2009 00:00

A Portfolio of Processes

Rate this item
(0 votes)

Many companies have some form of a portfolio management group to manage their projects and their backlog. The projects they govern range from network pulls to new software development. However, most use only one methodology to run these projects. It may be waterfall, Agile, Critical Chain or some other process. This is analogous to having only one knife in the kitchen. Anyone that has cooked more than a few meals realizes that a table knife is insufficient for all your kitchen needs. It purees tomatoes, cuts meat poorly, fails at filleting fish and suffers as a steak knife. There are hundreds of knives, each designed to do some specific job. As with many jobs, some tools are better than others are for certain tasks.

So why do so many companies use only one methodology for running projects? Each methodology has its own value. If the project is to pull network cable or to do a software upgrade, something where the requirements are well defined, it makes sense to use classic waterfall processes. However, if the assignment is to build a new system, one where the users are unsure of exactly what they will need, then they should use Agile.

If the project is longer and requires sharing resources within and between projects, one that is well defined, but the timeline needs to come in as far as possible, then use Critical Chain. Use different knives to cut through different types of projects. This is simply a matter of applying the correct project management tools appropriate to the situation at hand.

Even in a project recovery, many of the concepts of Agile and Critical Chain are very valuable in getting failed projects back on track to deliver value to both the customer and the supplier.

Failed projects can benefit from one aspect of both of these without the subject of methodology ever being broached—dedicating resources. When a project starts to fail, managers relent to dedicating resources to tasks. The reason is that the project is now a higher priority. Since this works so well, why not do it all that time? The people doing the work know they are far more efficient if they are left to do their task, uninterrupted by meetings and tasks for other projects. Managers must know this since they approve it for high-priority and failing projects. Therefore, it is baffling why this is not done all the time.

Most managers have learned the most effective way to build customer trust and team morale is to deliver something the customer can play with. A prototype of some feature, something with buttons to push or screens to ogle, brings vitality to the project a sense of esprit de corps. It gets projects moving and starts to break down the fears, angst and mistrust. It also starts reprioritizing requirements. Once the features are seen, their relative value is more apparent. What was once important is no long needed and the unimportant is critical. Getting something tangible to the customer calms the project, gains trust and stabilizes the scope.

Apply this in the beginning and the problems may have never occurred. It takes a chef in the project office’s kitchen with the expertise to grab and use the right tools as the recipes are being assigned to the staff. This will keep the projects from falling into the ugly abyss of failure.

Read 7086 times

Related items