How to stay on top of multiple software projects

Programme and portfolio managers are under increased pressure to make sure that a growing number of large software projects –

that, in large organisations, can involve thousands of team members – are delivered on time. It’s incredibly challenging and has become even more common in recent times, largely because more organisations are now attempting to handle these projects in-house.

A bank, for example, may have thousands of developers and testers, working on various projects for various departments. Linking their activities to the overall goals of the bank is not straightforward.

Suppose the senior management team has set a goal of attracting more customers who open current accounts. What IT investments will result in more current accounts being opened? Should the focus be on better marketing, more efficient back-office processing or improved user features such as debit card freezing?

A portfolio manager may make intelligent guesses as to what investments will be most effective in producing the desired result, but until there is some evidence to support one option or another, they are just guesses. At this very macro level, tracking a mass of project data, such as releases or story points, will not easily yield much guidance on how to achieve the goal of increasing the number of current accounts opened. Instead, one has to try out different hypotheses (e.g. more efficient back-office, more user features etc.) and, in turn, check whether or not there is a corresponding increase in the number of current accounts opened.

This exercise should help managers understand which areas of IT to invest in to have the best chance of achieving the organisation’s strategic goals. The next task is to work out at a lower level how best to maximise investment efficiency, maximise completed useful projects per month, and pound spend.

Balancing creativity with consistency

In managing multiple software and IT projects, how should one assess the investment of money and resources against the benefits for the business? Even when working at the division or business unit level, rather than that of the whole enterprise, scale can still be a major challenge. Each project will have its own manager, sub-team managers and team members – and each team will have its own way of working – but to enable meaningful reporting, there needs to be a degree of consistency throughout the organisation, especially in the ways in which progress is documented.

Inconsistent reporting across teams will occur unless a degree of standardisation is agreed between them. Without standardisation, each team may use different metrics for measuring progress, and have different definitions of similar metrics. For example, two different teams may have completely different norms for the amount of progress represented by a story point.

It is easy to see how this could create a major problem for senior management. A degree of standardisation is essential for consistent reporting, but too much standardisation can stifle initiative and creativity within the teams. A balance must be struck between ensuring enough standardisation to permit consistent reporting and freedom for the project teams to customise their working methods – to promote initiative and creativity and maximise efficiency.

Portfolio management

Various tools exist to permit the management of a portfolio or collection of projects. These tools enable releases to be co-ordinated across projects, and resources to be allocated to different projects to enable cross-project releases to be made. For example, if one project in a portfolio is forecast to finish after a planned release date, the tools can model resource allocation to find a solution (if such a solution exists) such that resources are reallocated to the lagging project without delaying other projects beyond the release date. An example of such a tool is Portfolio Management for Jira, which can manage a portfolio of Jira projects.

Portfolio for Jira is effective up to about 150 projects. Above this number, it is better to rely on a standard reporting framework which also permits customisation at project level. One way of doing this is to impose standard reporting requirements at the upper levels of the agile hierarchy (e.g. epics, releases and groups of releases), but permit customisations at the lower levels (e.g. sprints and stories). This approach not only permits standardised reporting, but prevents wasteful creation of reports in many different formats, or reporting of data generated by a project management tool like Jira in another tool like Excel or PowerPoint.

If a consistent approach to reporting is adopted through the organisation, it is possible to secure cultural adoption of the standard, and promote efficiency in the generation of management information, and effectiveness in its use by management.

Managing pressures on IT infrastructure

Project management tools like Atlassian’s Jira Software are highly configurable. This helps it to fit a wide range of business processes and project management styles, and makes it popular with project teams. The downside is that if every project has its own configurations, the performance of the project management tool can be adversely affected. Again, a balance must be struck between allowing projects the freedom to innovate, while preventing the creation of a mass of customisations which slows the system down. Typical configurations include custom fields, workflows and issue types.

Rather than allowing teams to create customisations at will or completely banning them, processing requests through a helpdesk can be a worthwhile compromise. For a given customisation request, the helpdesk can tell if a similar customisation already exists and can be used by the requestor; it can take a view on the likely performance impact versus the benefit of the customisation; and it can advise on the most efficient way for the requestor to achieve the result they want. Beyond this, the helpdesk can maintain Jira and regularly remove obsolete configurations, thus keeping performance acceptable.

With Jira, it may also be necessary to consider software deployment options. As the number of users and issues grow, the demand may become too much for a single server to manage. The potential cost of downtime can reach the point where it makes financial sense to move to a clustered architecture, which requires the ‘Data Center’ edition of Jira. Data Center costs more, but permits high availability, greater resilience and zero downtime upgrades. From about 2,000 users or more, these benefits start to become worth the additional cost.

Training

The effective management of many software projects relies even more on the human element than on the processes and tools. It is essential to have suitably qualified people in the right positions – this not only means experienced project managers, but also people you can train as ‘power users’ of your project management tools and the other vital software options.

These ‘power users’ are crucial in overcoming most the challenges mentioned: they can help establish consistency for how the tools are used, address IT issues, instruct other users on best practices, encourage creativity, and ensure that project goals are met on time.

Spending the time and money to train project managers, power users and senior managers is an essential investment. Training should include instruction not only in standard agile at scale methodologies such as SAFe and DAD, and the organisation’s project and portfolio management tools, but also in the unique standards the organisation adopts for reporting.