Successfully Delivering a Software Project

You have decided to replace a key system, you have defined what you require and have selected the solution best able to meet those requirements so how do you deliver that project successfully to time and budget?

The trouble with technology, or process improvement, projects is that, even when buying packaged software, no two projects ever seem to be the same and there will be requirements that are unique to your organisation, particularly if there is some level of customisation   

However there are some sensible measures that can be taken to ensure project success: 

1. Have a plan. It sounds obvious but it is amazing how often projects don’t and if you don’t know where you are going you will end up somewhere else.  Your plan needs to be understandable and manageable so as with requirements gathering ‘big is not always beautiful’. The plan should be appropriate to the size of the project but make sure you have a plan and that it is understood. A 1000 task project plan is not something to be overly proud of as most people will not understand it and so something will go wrong.
2. Manage the Plan. The plan is not just a deliverable to be filed. It has to be managed as it will not look after itself.  Things will happen that may cause you to review the plan and possibly to adjust it. This doesn’t mean micro-management but it does mean regular project meetings both for the project team and the senior stakeholders and there needs to be a log of real risks and issues, i.e. ones that really will impact the project not hypothetical ones that fill up the log.
3. Manage Change: The plan and the project are not set in concrete. It is a fact of project life that requirements change. This can be for a whole bunch of reasons, the original requirement was misunderstood or a new requirement as a result of a strategic change in the organisation.Whatever the reason you need a process to manage change, so that those involved in the project understand how much it will cost, why it is necessary and the impact on the overall project. Then the decision can be made as to whether the change should be approved and when it should be implemented.
4. Be realistic with the Go live date. One of the reasons why software projects fail is because of unrealistic timescales. There are a number of reasons for this. Firstly there is the perception of it being packaged software, but with all packaged solutions there will still be configuration and testing as well as some elements such as interfaces and data migration that will be unique to that project. If there is an operational or legislative reason why the solution needs to be implemented by a certain date then that needs to have been incorporated from the beginning of the project. There is the tendency to be too optimistic but issuing deadline after deadline will only lead to distrust and aggravation on the part of the client and it takes a strong project manager to propose a realistic plan.
5. Manage expectations. Know who your stakeholders are and ensure that they are involved and informed. They all want the project to be a success but they want to know what is happening, when and how it will impact them. In particular nobody likes surprises. Ensure that there is regular communication appropriate to the stakeholder and their level of involvement.

Selecting Packaged Software

Selecting business software can be difficult. You know you need a new system, but how do you go about finding the correct solution for your needs? 

Finding the right software can be a challenge but the correct approach to selection will hopefully enable you to avoid the pitfalls, and having the right supplier to implement the chosen solution is just as important. 

Hopefully the following will help you to avoid some of the common pitfalls that companies make:

1. Selecting software is a project in its own right. It needs a plan and it needs a Project Manager. Most organisations have specific target dates for implementing new software, whether it be a strategic initiative or a legislative requirement. But without a plan, as in all things, you probably will not achieve it. 
2. Involve all stakeholders. Whether the original impetus for changing the solution was business led or technology led you need the input and buy-in from all the constituent parts that make up your organization. Ensure you understand the procurement process and that all the correct people are engaged from the beginning
3. Why are you buying a new system? Too many businesses purchase software thinking it will solve their problems when, in fact, the problems are actually due to business processes. Software is only a tool, although it may help you to focus attention on the bad processes and other internal problems that need to be addressed.
4. Do you know what you want? Do you know your requirements for the new system? If not stop and go no further until this has been done. It doesn’t have to be laborious but you should at the initial stage be able to document your key requirements, those criteria which differentiate your business, onto just a few pages. As a minimum you should know your key processes, end-to-end, and that includes their impact on other systems or organisations and hopefully the key areas that you are looking to improve. Knowing your requirements also includes knowing your budget. There is little point in looking at a Ferrari if you can only afford a Fiat, even if the Ferrari meets all your other requirements.
5. Assessing the software through a scripted software demonstrations. Initial software demos may be guided by the supplier but when you get to the shortlist you need to assess the solution based on your requirements. So at that point it should be a scripted demo. If the supplier can’t or won’t do what has been requested you should be asking why.
6. Assess the solution implementer. Some software packages will be implemented by a third party. so not only are you assessing the solution but you also need to assess the company that will implement.No matter how good the software, the set-up and configuration will only be as good as the company implementing it. So when you get to site reference visits you need to be referencing not only the system but also the implementer.

Getting Your Software Requirements Right

When selecting software, getting the requirements right is absolutely key to the success of the project. They are effectively the foundations for all that you to want to achieve.

If you get them wrong you will either end up with something that doesn’t meet the requirements and you have to start again, or it will add significant delay and cost to the project. 

So here are some principles for getting the requirements right:

1. If it is not written down it has never been said. It doesn’t matter if you talked about what your wanted at length, what matters is what was written down. And it is all that matters if when  the solution is delivered you discover that a key piece of functionality is missing
2. You don’t know what you don’t know. Get the prospective supplier to demo what is available in their system 
3. Do not design your system around exceptions, particularly if doing so requires customisation. Consider how the process might be catered for outside the system. Do you really need to allow for snow in summer?
4. Do not determine your requirements in silos. Consider the end to end process and make sure that you involve everyone that needs to be involved.
5. Customisation should be a last resort when buying an ‘off the shelf’ system. Question why your organisation is so different to anyone else.
6. Do not create a replica of your existing system, remember that there is a reason why you wanted to replace it. 
7. Big is not beautiful, when documenting your requirements. A 700 page requirements specification is not something to be proud of. Break it down into bite sized chunks so that it can be understood and signed off.
8. Take into account corporate strategy. Don’t just design a system for you immediate needs. Does your company plan to expand into other countries? What other systems are being replaced? What will happen if another company is acquired?
9. Something will get overlooked, hopefully it will be minor but you need a process to manage change so that you can make an informed decision in terms of impact to the business, as well as impact to the project including the budget.