Planning risks for small and medium enterprise software projects

By Peter Meyer, Principal Consultant, Elkera Pty Limited

A high proportion of software projects under perform or fail

According to reports by analytics companies such as the Standish Group, only around 30% of software projects are rated as successful. Most projects fall short in some way. Depending on the tests applied, around 20% – 25% of projects fail completely.

The consequences of failure for affected organisations are serious, including:

  • wasted investment
  • lost business opportunities
  • damage to employee morale and feeding of change cynicism.

The definition of a successful software project

To understand the sources of failure, the best place to start is to look at the definition of success. A successful software project must:

  • Solve real business problems and satisfy defined business objectives.
  • Provide an acceptable return on investment, based on the business value provided and the cost of acquisition and support over its expected life.
  • Satisfy the system users.

Each of those elements is highly dependent on effective project planning. Once the planning is complete, the choice of solution provider and then solution delivery become vitally important. However, without a good foundation in planning, the delivery elements of the project are almost certain to fall short of expectations or fail.

Essential planning inputs for a successful software project

Here are the essential planning inputs for a successful software project, taken from an earlier blog article; Seven critical activities for successful software project planning:

  1. Analyse and clearly define the organisation’s problems, business needs and objectives, based on inputs from all relevant stakeholders.
  2. Analyse all affected workflows and business processes, assess them for improvement and simplification, and design a new or improved way of working.
  3. Assess the benefits of all functions proposed for the new software to determine their business value. Assess technology and other risks as part of that process.
  4. Assess the maximum investment that should be made to secure the expected benefits.
  5. Develop a specification of requirements that is aligned with the nature of the expected solution and the proposed procurement process.
  6. Prepare a procurement plan to guide identification and selection of a solution provider.
  7. Develop a change management plan to guide all organisational change, training, deployment and internal support.

These inputs are necessary for just about any software project, large or small. However, each input must be aligned with the specific needs and scale of each project to avoid excessive overhead.

If the project planners effectively cover those inputs, the project is likely to be set up for success.

If any of those inputs are missing or are not been undertaken effectively, there is a risk that the solution delivery phase of the project will be undermined. The project is unlikely to achieve all of its potential benefits.

The problem for small and medium enterprises

Many small and medium enterprises (SMEs) are at a particular disadvantage when it comes to software project planning, as explained in my earlier blog article; Seven critical activities for successful software project planning. SME disadvantages include:

  • Managers of SMEs often are not experienced at guiding software projects. They may not appreciate the risks involved or planning activities that are required.
  • Many SMEs do not have expert business analysts or project managers on staff. Project planning may be undertaken by inexperienced, in-house personnel.
  • As a result of the lack of expertise, projects are often left to, or initiated by, the manager of a particular area of the business and planned without effective consultation with other stakeholders.
  • Many SMEs do not have a strategic or master plan to guide and prioritise systems development. Individual systems may not be well coordinated.

Ineffective planning is the main source of SME project failure

Disadvantaged SMEs are unlikely to be able produce the essential planning inputs without expert assistance. Unfortunately, the nature of the disadvantages often leads SMEs to avoid seeking expert assistance. SME managers who do not appreciate the risks are unlikely to seek help.

It is likely that disadvantaged SMEs are over represented in the project failure statistics.

The only solution to this problem is education, either through learning from failure or in a more pedagogical way.

A risk-based framework for understanding the essentials of good planning

To really understand why all the planning inputs described earlier are necessary, it is useful to consider the likely sources of failure in the planning phase by identifying common software project planning risks.

Software project planning risks are assessed in five categories:

  1. Project management risks
  2. Business analysis and change planning risks
  3. Business case risks
  4. Technology and business context risks
  5. Requirements elicitation and documentation risks.

These categories help to anchor the risks in one or more of the essential inputs listed earlier in this article.

Common planning risks in each category

Project management risks

Core project management risks include:

  • Using unskilled personnel for planning. This risk will be given specific attention in a later topic.
  • Failing to align the objectives of a discrete project with organisation wide needs (failing to have or align with a master plan).
  • Failing to limit project scope to the capacities of the enterprise.
  • Setting unrealistic deadlines, which leads to incomplete analysis or delay.

Business analysis and change planning risks

Business analysis and change planning risks include:

  • Failing to understand and clearly define the business problems that are to be solved.
  • Failing to include important business process stakeholders in planning.
  • Failing to focus on customer or end user needs.
  • Failing to set clear, measurable objectives (success factors) for the project.
  • Failing to analyse, and plan to optimise, business processes affected by the proposed software.

Software projects almost invariably require significant process and workflow change. If the need for change is ignored or underestimated, all subsequent planning work is undermined.

Business case risks

Business case risks include:

  • Failing to critically evaluate the expected benefits of proposed requirements.
  • Failing to prioritise proposed requirements based on business value and risk.
  • Failing to establish a clear business case with a positive return on expected investment.

Technology and business context risks

Technology and business context risks include:

  • Making unfounded assumptions about the technology or product required for the solution.
  • Expecting to use emerging technologies.
  • The solution would require bespoke software.
  • The solution would require heavily customised, off-the-shelf software.
  • The business operates in a rapidly changing business environment that either prevents a clear definition of requirements up front or may lead to significant change during the project.

Technology and business context risks increase project complexity and the risk of failure.

Requirements elicitation and documentation risks

Requirements elicitation and documentation risks include:

  • Including user ‘wish list’ requirements without critical assessment of need.
  • Failing to include the interests of all stakeholders.
  • Not including business context information with requirements so that solution providers understand the “why”.
  • Incomplete requirements, such as by failing to include non-functional requirements, data migration requirements and other change requirements.
  • Failing to define requirements in a form that allows stakeholders to reliably assess if the requirements are satisfied by a delivered solution (ambiguous requirements).
  • Failing to align requirements with the nature of the expected solution and applicable assumptions. The requirements for an off-the-shelf system will be quite different to those for a bespoke or heavily customised system.

Defective requirements will certainly undermine the value of the delivered solution. If the problems are severe enough, they may completely undermine the project to the point of failure.

Conclusions

Taking together the essential inputs to a successful project and the common risks, it is easy to see why so many projects under-perform or fail. Business software projects are particularly risky undertakings for SMEs that do not have experienced management and expert project planning personnel.

It is not realistic to expect unskilled personnel to navigate each of the listed risks and produce the required planning inputs. Using unskilled personnel for such a complex process is likely to be the biggest single risk factor because it magnifies every other risk.

To avoid the planning risks and to effectively develop the essential inputs for a successful software project, SMEs should engage expert assistance for software project planning. In so doing, they will avoid serious financial risks and maximise project benefits.