• Project, Programme and Portfolio Management
• No comments

INVESTING IN THE PURCHASE AND CONFIGURATION OF SOFTWARE TOOLS.

Having put in place the project management processes that define how plans and logs, supported by templates and reports, should be used as the prime tools, there is an option to improve efficiency by investing in the purchase and configuration of software tools. Before doing so, I strongly suggest that the organisation’s processes are rolled out and embedded for a reasonable period, using existing unsophisticated software tools, to gain confidence in (and improve the likelihood of) achieving successful implementation and adoption of an expensive project management software package.

Selecting the Software Tools that Give Best Value for Money

There are numerous software packages on the market that can be configured to help organisations to manage their projects, so selecting the package that will provide the best value for money is not easy. It may be preferable to buy a cheaper option that achieves most of an organisation’s requirements, rather than a more expensive option that satisfies all of its requirements, as long as the lost functionality does not require significantly greater effort from the project community. This is the balance that needs to be found, which should be possible to estimate and include within benefit and cost comparisons. In order to select a project management software package, I suggest the following process:

Create a list of requirements

Based on what we have discussed so far, I propose the following list of user requirements that should form the basis of selecting the best software package:

Dependent upon the organisation’s IT strategy, there are likely to be some technical requirements that should also be listed, along with any additional organisation specific user requirements.

Create a list of project management software options

An internet search of ‘project management software’ will reveal an abundance of software packages that could be considered. There are also numerous websites that provide comparisons of software packages. By researching the details and comparisons of what is on offer, it should be possible to list those that are worth considering in relation to the list of requirements.

Estimate the benefits and costs of each option

For each listed software package, it is worth objectively rating the capabilities of each of them in relation to the list of requirements (e.g. 0 to 5), from which totals can be calculated so that the list can be ranked in the order that best fits with the set of requirements.

For each option (or perhaps, say, the top 10) it should be possible to obtain rough estimates of the initial and ongoing software, hardware and support costs. Also, it should be possible to calculate any significant differences in resource savings, relative to either the highest or lowest ranked option, based on:

estimated time saving per project x number of projects x resource cost rate.

The list of options can now be ranked based on cost (or perhaps a 0 to 5 cost rating).

Note that the benefit and cost estimates created above also provide useful data that should be included in a Business Case, along with data or estimates on lost value due to poor project performance.

Arrange demonstrations of the best options

The two ranked lists of options should now provide a clear shortlist (of say three) of those which are most worth investigating in more detail. To achieve this, I suggest providing the list of requirements to each supplier, so that they can provide both a list of responses and a demonstration of what capabilities their product includes to satisfy the requirements. During each demonstration, you should refer to the supplier’s list of responses to gain a clear understanding of how well each product matches up.

Be aware that some software packages have some surprising shortcomings (in relation to the proposed list of requirements) which may only come to light when you get into the detail, so it is important not to commit to anything based on a superficial understanding of a product’s capabilities. If you find that one or two of the options that you have selected for your shortlist have fundamental capability shortfalls, it may be worth bringing in the next highest ranked package (or two) on your initial list, depending upon the relative scores.

Review the benefits and costs of the best options

Having gained a clear understanding of each of the software packages on the shortlist, it is now possible to review how well they match up against the requirements. Similarly, it should be possible to firm up the costs with each of the suppliers and gain their commitment to the best deals that they can offer, making them aware that they are competing for your business.

Select the best option

You are now in a good position to make an informed and ‘objective’ decision of which software package to purchase and finalise a Business Case. I strongly recommend that when you advise the successful supplier of this, you make it provisional, dependent upon a satisfactory reference (or two) that they should provide for with.

Check the selected option with another organisation

If possible, it is best to check that other organisations are achieving success with the software tool you have selected before finally committing to investing in it. Whilst you should be able to gain some confidence in the product from reviews on the internet, it can be very valuable to check any details you are unsure about with another organisation (or two) and also gain their overall impression of the product. As mentioned previously, this discussion could be set up by your chosen supplier as a purchasing condition.

Optimising the Configuration of the Software Tools

Most project management software packages are highly configurable, so the level of successful adoption will be greatly dependent upon how well the selected software package is matched to the specific project management processes of the organisation.

One of the requirements for selecting the best software package was that it should be easy to configure and administer. In which case, it should be possible for suitable internal resources to conduct the configuration work, although they will probably require some training beforehand.

Configuration consists of the following elements:

• functionality settings
• security settings
• creating a central resource pool
• creating bespoke fields
• creating views and reports

Functionality settings

These settings generally have a number of options, from which the appropriate one needs to be selected. For example, there are likely to be options in terms of the update cycle, to enable manual progressing of plans or uploading of task update data supplied from team members.

Security settings

These settings restrict access to data and to functionality. For example, it might be appropriate that only certain users (or groups of users) have access to specific views or reports or to particular projects. These may be defined by simple rules, for which the toolset provides configuration options. Similarly, it may be appropriate that functionality relating to such things as the configuration settings, the central resource pool and setting baselines are limited to a very small group of administrators of the system.

If possible, it is generally recommended to apply security sessions to groups and then add users to appropriate groups, rather than apply permissions to individual users, to reduce complexity and administration effort.

Creating a central resource pool

In order to be able to assign common resources across plans, a central resource pool is required. This should include role-based resources (e.g. Project Manager) to include all of the roles that projects may need to plan early in the project lifecycle, as well as all of the specific resources that may be substituted for the role based resources later in the project lifecycle.

Once the resource pool has been created, it should be centrally administered thereafter, preferably restricted by security settings, in line with starters and leavers.

Creating bespoke fields

Software packages usually include standard fields and have capability for system administrators to create additional bespoke fields. In addition to the fields previously listed for each of the logs, bespoke fields are useful for ‘tagging’ plans, tasks within plans and resources assigned to tasks, with attributes that enable grouping, sorting and filtering of data for reporting purposes, alongside data from the logs.

The Portfolio and Project Summary reports include fields that should be possible to configure, so that production of the reports can be automated. Other bespoke fields might include calculations of variances and RAG indicators (of schedule, effort and cost) for individual tasks within plans, if they are not provided as standard fields. It may also be useful to be able to tag resources with their competencies (to help selection of specific resources) and the organisational function (e.g. department) to which they belong. It should be possible to create fields as different types such as:

• Text
• Number
• Currency
• Person

It should also be possible to link bespoke fields to lookup tables which have centrally defined and controlled lookup values that are selectable by users.

Creating views and reports

A good software package should make it easy to ‘slice and dice’ the data, so that the various users can view sets of data that are grouped, sorted and filtered as they desire. It should enable individual users to easily create the format and content, based on standard and bespoke (configured) fields, save and print the individual report and also save what they have created as a ‘template’ for future use. It is more likely that this will be possible in spreadsheet type formats than in the formats that are generally accepted for formal reports.

To achieve automatic creation of standard reports, whereby the software tool populates the content of it into an attractive preformatted template document (perhaps including images such as a logo), usually requires more complex configuration work or may even require a resource with very specific skills in report writing applications. It is important, therefore, to ensure that the organisation has, or develops, the skills to create and adjust reports such as these, so that enhancements are easy to implement as the organisation improves its project management maturity.