Implementing Software

Software projects fail when they solve the wrong problem, or no one uses them. If a project delivers there should be so much value that cost overruns aren’t the issue.

If you build it, they won’t care

Given a choice between missing the mark slightly and lack of engagement, the latter is by far the most difficult to live with. If the people with the challenge are engaged and software is missing the mark, then feedback and communication will help steer the project closer to the mark.

The key innovation of agile ways of working is the engagement and feedback of stakeholders and most importantly the end users.

SaaS projects are rarely just choosing the product, get the licences and walking away. Implementation is the most important part but also normally the most neglected. With the amount of potential for configuration in most SaaS products the implementation is the real project and the product the platform that it’s built on.

Along for the journey

Stakeholders and users should be involved in all stages of the implementation, gathering the requirements, choosing the product and implementing the configuration. A core group of people representing the business needs should be present and engaged with the result from the start to end of the project.

A wider group of people also need to be brought along for the journey, the core group should make sure the communications are regular but also hold Q&A sessions that give people the opportunity to inform the process and allay any concerns.

Checklist

To keep things concise, here’s a checklist of the key things to do. This checklist could apply to any project not just a Software or specifically a SaaS one.

Why are we doing this

For any project that involves business change it’s vital the reasons for the project can be clearly articulated. Something as vague as “efficiencies” is so vague that it’s at best pointless and at worst very negative because of its link with redundancies.

In a previous post we mentioned linking requirements to KPIs, the same approach should be used to clearly articulate the reasons for a project; “we are implementing this CRM to improve the percentage conversion of leads and improve customer retention”. An even better version of that statement would include current and projected percentages and exactly how the project will change the numbers.

Core group

In all projects decisions need to be made, to avoid delays the group making the decisions should be small and empowered by the wider business to get on with things. A useful principal is to agree that the group is empowered to make decisions so long as those decisions are clearly communicated to the wider group on a regular basis.

Managing upwards

Senior stakeholders can magnify or minimise the impact of projects, a project shouldn’t even be started without clear buy in from all the senior team. Implementing a CRM that the Sales Director doesn’t want isn’t going to end well.

The process of senior stakeholder buy in is a combination of sales, marketing and dealmaking. It’s also frequently the difference between success and failure.

Regular comms and feedback

A project starting with great fanfare and expectation and then disappearing for a year does not win over hearts and minds. Regular, reasonably high level, comms to the organisation is incredibly important. Sending out a RAG status in a spreadsheet once a week isn’t going to make anyone care.

Project comms is far closer to an internal PR exercise then project communications, a previous colleague produced a movie trailer for a telephony project and then followed up with something as innovative every week for the next three months. People were interviewed, games were played, not a spreadsheet in sight.

Training

If on day one of a project going live anyone sits down and doesn’t know exactly how to do their job, then you’ve lost. Training should be specific for each team and their requirements. Ideally training should be done as a group and repeated.

Anything that an individual completes alone at their desk will be forgotten instantly, along with every health and safety training onboarding that has ever been done.

Expectations

It is important that all the members of the implementation team, senior management and users understand from the beginning of the project what is expected from them in order of the project to be successful. That could be turning up for training or steering committee meetings.

Realistic timeline

Unless the project is particularly unusual it is unlikely that the challenges will be technical ones. Most of the time is take up with the people side of the implementation so it’s important to be realistic about how much time that will take and bake in enough time to do everything twice. Smaller teams can change direction a more quickly than large teams but still need to be brought along at a sensible pace.

Wrapping up

Businesses have a technology “hierarchy of needs” starting at the bottom with requirements that they share with nearly all other businesses, telephony some form of office suite (O365, Google etc.).

When transforming a business, it’s important to start with the requirements lower down the hierarchy, the tools will require less configuration and confidence in change can be built up.

Also, these more “standard” projects will allow for far more focus to be given to the people in the organisation. Good practice for the more complicated industry specific projects that the business will encounter later.