Essential first steps for SMEs to start a new software project

By Peter Meyer, Principal Consultant, Elkera Pty Limited

Are you working in a small or medium enterprise (SME) that needs to replace obsolete software or to acquire new software to improve the business?

Perhaps, you may have an idea about a business improvement that could require new software but you are unsure about how to turn it into a project that will be supported by management.

Getting started on a new software project is difficult. How do you work out what you really need? How do you get management to support your initiative?

SMEs are at a disadvantage when planning software projects, compared to larger enterprises. SMEs may not undertake software project very often and may not have the in-house expertise that is required to maximise the benefits of their projects and avoid the many risks.

This article identifies some of the essential first steps that anyone planning a new software project should take to set the project on the path to success.

It is all very well to list and describe a set of actions that planners should take, but will people in the organisation actually follow them?

In the writer’s experience, often the answer is no. Something more is required, a deep understanding of why each step is necessary. To try and address that problem, the first set of steps focus on establishing the right mindsets among project team members to guide their thinking throughout the project.

Thus, there are two categories of essential steps:

• Establish and maintain essential mindsets among internal stakeholders
• Essential planning actions.

Establish and maintain essential mindsets

Five mindsets are identified that should be established among key project stakeholders if the project is to go well. Work to establish those mindsets from the first gathering of project stakeholders. Then work on maintaining them through all planning work. It is the writer’s experience that the absence of these mindsets, and the actions that they drive, that is the root cause of many project failures.

Mindset 1 – Inquisitiveness – Dig to the bottom of problems by asking why

In most business contexts, problems are not always what they seem. It is easy to take a superficial approach to problem identification. If the real problem is not defined, a supposed solution is unlikely to solve it.

Business analysts are trained to ask why, repeatedly, until they have uncovered the root cause of apparent problems. Everyone involved in the project should adopt that mindset. At every stage of project planning, they should step back and ask:

• what problem does a particular suggestion solve?
• What is the real cause of that problem?

A dig to the bottom mindset will avoid superficial solutions and minimise the need to revisit problems not properly considered the first time.

Mindset 2 – Think business value – Rigorously assess project objectives for their business value

A business cannot spend money on a project that does not have an acceptable business case. The first part of a business case is to define the project objectives and their expected benefits.

When thinking about solutions to problems, think about them in business terms, not as features of a software product. The real question is to ask: “what should a solution do for the business?”. That means defining business objectives, assessing the benefits and placing a value on them.

A new software product must enable the business to reduce operational costs, provide a new or better product or service, meet a compliance requirement, or similar. Those goals have an expected value to the business. The expected benefits of each objective must be defined if there is to be a meaningful business case.

Many project stakeholders will propose features from their wish list that they assert must be included in the new software. Some of those features may be useful and some not. Wish-lists are good, they generate ideas. Those ideas must be assessed and prioritised. They will have different values to the business. It is essential that everyone involved in the project thinks about suggested solutions to problems in terms of the expected benefits to the business. Every function or feature of software costs money and must provide valuable benefits to be justified.

A business value mindset will focus the attention of those involved in planning to look for new ways to enhance business value through the project. It will enable you to prioritise proposals and focus on those that are truly value-enhancing for the business.

Mindset 3 – Systems thinking – Think of software as part of a system

In the writer’s experience there is a tendency for many people to view a business software product as “the solution”, rather than just a tool that is to be part of a broader system. That mindset could be described as a modern form of cargo cult thinking.

Business software does nothing on its own. It has to receive inputs and deliver outputs. Those inputs and outputs are driven by business processes and workflows with employees, customers and other stakeholders. The software in the context of its inputs and outputs makes up a system.

Planners who think of software as part of a system are forced to understand how the business works, at a detailed level. They need to know what the system is meant to deliver, and to whom.

From that understanding two conclusions follow:

• System processes must be optimised to reduce wasteful or redundant processes and to align them with the way that a software system should work. If that is not done system costs will be excessive and many potential benefits may be lost.
• The needs of every stakeholder in the system must be understood.

These themes are picked up in the next topics.

A system-oriented mindset will focus attention on business processes, stakeholders and their needs.

Mindset 4 – Openness to change – Expect change in the way you work

A very common scenario in new software planning is for personnel to expect the new system to just help them with the way they currently work. For example, personnel may use spreadsheets to gather data in a form that lets them and others see a current state of information. All too often, the new system is expected to replicate that spreadsheet as a report.

Replicating existing processes in a new software system almost certainly will add to the costs of the system. It will undermine many of the benefits that should be expected. Moving from manual to computer automated processes requires a complete re-thinking of how everything works.

Some people may find it difficult to envisage a different way of working. They may fail to appreciate that the limitations of their current system may create huge inefficiencies that should be eliminated. Some may have a general perception that things don’t work but be unable to pin-point the problems.

Effective project planning requires that all existing processes are thoroughly reviewed and that requirements for the new software are based on optimised and simplified processes, wherever possible.

The need to consider change should be communicated to all personnel from the outset. With early and cogent explanations, most personnel will participate willingly in the journey. If some are resistant, that should be understood as early as possible.

Establishing awareness of the need for change provides a foundation for further change planning.

Mindset 5 – Inclusiveness – Include all stakeholders in planning

Often, proponents of a software project consider the project solely from the needs of their own business unit. They may have limited awareness of the possible effects on other areas of the business. There can be a resistance to engaging with other managers because doing so slows things down and increases the effort required.

It is essential to include every stakeholder in the system. Understanding all stakeholder needs will enable good decision making to maximise the potential benefits of the system.

An inclusive mindset will ensure that all stakeholder interests are properly considered and prioritised.

Essential planning actions

Now let’s look at the key planning actions. This is not an exhaustive list, but some of the most important steps to set the project on a path to success.

Action 1 – Define the problems that the project is to address and the project objectives

Now it is time to set write down the problems and the project objectives.

If you have taken on the mindsets discussed in the previous section, you will be in a good position to take the right actions.

Key points to consider include:

• Define problems in terms of their effect on the business.
• Similarly, define objectives in business terms, not software features.
• Identify who is affected and how.
• If possible, begin to place values on the cost of problems and the expected benefits from meeting the objectives. Those values may be only broad ranges in the first instance.
• Don’t try to anticipate the technical solution, unless that is absolutely locked in, based on existing systems.

One of the big problems with systems projects is to work out the limits of the system. How far into related processes do you try to extend the system. For example, you may wish to acquire project planning software. Should it exchange data with the finance system, the payroll system and the HR system? These questions may require detailed analysis.

It is important that the benefits and risks of connecting multiple systems are clearly assessed and understood.

Once the problems and objectives are defined, you have the first draft of a project charter.

Bear in mind that the first pass won’t be the end result. There will be a lot of investigation and prioritisation in the following steps that will require you to revisit your earlier drafts.

Action 2 – Start work on the business case with Action 1

A business value mindset was the second mindset discussed in the first section of this article.

A software project should not go anywhere if it does not have a clear business case.

Early in the project, you can only estimate the benefits side of your business case. It is unlikely you will be able to estimate the costs of a software system that may be needed for a solution. The cost side will come much later. Using your benefits assessment, you will be able to assess the acceptable level of investment to secure those benefits.

When you are determining the scope of your project under action 1, it is essential to prioritise proposed objectives by their business value. That means you have to begin setting out the benefits side of your business case from the outset.

Start by writing down the problems with the current system and how they add costs to the business. Then write down the planned improvements and describe their likely benefits. Next, try to attribute some measure of value. In the early stages, you might just use T-shirt sizes, rather than numbers. What is important is to focus attention on looking for value.  Doing so will enable you to prioritise and then dig in to gather more detail.

Action 3 – Establish senior management sponsorship

A project cannot proceed unless it has senior management support. In the case of an SME software project, that should be at the operations director or CEO level. Most likely, that level of support will be required to have financial and personnel resources allocated to the project.

Senior management sponsorship is essential also to obtaining buy-in from other stakeholders.

If you have developed a project proposal, have defined the problems, established clear objectives and already have the outline of the benefits side of your business case, you are in a good position to make a case to senior management.

Action 4 – Establish a project steering group that includes representatives of all key stakeholders

Once the project has senior management support, a project steering group should be established to gather all key stakeholder inputs. The group should be led by the project sponsor. I leave out other governance issues at this time, as that will vary for each organisation.

It is important that all internal groups materially affected by the proposed system are represented. If the project is run for the benefit of one business unit over others, it will almost certainly undermine the potential benefits.

Action 5 – Engage an expert analyst project manager to help plan the project

If the organisation does not have in-house business analysts and project managers, this action may be the toughest. Managers may be inclined to allocate planning work to someone in-house.

You cannot expect management to agree to engage an expert consultant until:

• They accept that there is a valuable project,
• They accept that the skills required for effective planning are not available in-house, and
• There is a good business case for engaging a consultant.

If you have been following the advice in earlier topics, you will be ready to meet those challenges.

Understanding why an expert consultant is required

The first step is to persuade management that it is important to engage an expert to help with the planning. Reasons include:

• Is it a good use of personnel time to take them away from their normal duties?
• Business process analysis is critical to aligning business processes with the software. In-house, unskilled personnel are unlikely to have the required capabilities. It will be very difficult for a non-expert insider to take an objective look at business processes, plan their optimisation and lead everyone through the change process.
• Without the skills, in-house personnel will have difficulty prioritising requirements based on business value, rather than stakeholder wish-lists.
• Unskilled personnel may assume that a solution must be based on a particular product or platform. More effective approaches may be overlooked.
• Unskilled personnel are unlikely to know how to elicit all requirements and document them effectively to meet procurement needs.

The issues and risks in the planning process are many. It is very unlikely that unskilled personnel can achieve a result that will maximise project value.

Even with those reasons, management will want to understand the business case for engaging a consultant.

Making the business case for an expert consultant

Unless you have a business case for the overall project, there can be no business case for engaging a consultant. In the writer’s experience, this is the key reason that managers fall back to relying on in-house personnel. They can’t see the business case for engaging a consultant. Who can blame them!

Once you have established that a proposed project should produce substantial benefits, even if actual values cannot be attributed, you have the essential elements of a business case for engaging an expert consultant.

Without expert help, the benefits are unlikely to be fully realised, or the project may fail. With expert help, you should maximise the chance that you will fully realise the benefits. Most likely, an experienced consultant will identify additional improvements that should enhance your project business case and easily justify the investment in the consultant.

To make the business case for the expert consultant work, you should do the planning work in small steps or increments so that you can change course at low cost if things are not working out as expected.

Conclusions

There are five essential mindsets and five essential first steps that are critical to initiating and planning a business software project.

These mindsets and first steps can apply to any organisation, but they are particularly important for SMEs who  lack in-house project experts.

The core themes running through all mindsets and steps are to dig down to fully understand problems, focus on business value, apply systems thinking, expect change, include all stakeholders and engage expert assistance..

If you work to build and maintain the five mindsets and follow the five initial planning steps, your project will be set on a path to success.