Software Development & Systems Implementation Delivery Best practices – General Advice – Part 1

This post discusses some of the best practices and delivery approaches for implementing software solutions and development projects.

The post is purely a personal view which some people may agree or disagree with some or all of it. I do not claim that there is only one way of delivering any project but I think those best practices in my own view can make your delivery a bit more structured and hopefully smoother.

Some advice for your software system implementation based on the various projects that I’ve delivered and been involved in:

* Make sure the client and their business stakeholders are completely involved in the project and fully aware of your plans, your progress and have frequent and regular discussions on the project status.

* Perform as many demos and presentations to your client stakeholders and their wider business including your future system users. Early view into your solution will mean less panic, worries and complaints when you reach the User Acceptable Testing (UAT) phase. If they see it for the first time in UAT, there will most probably be complains and feedback as it is a new system for them.

* Projects that are business led have better chances of succeeding than those purely led by an IT team. Make sure you got the full buy-in and acceptance / agreement from the business that what you are building is what they want.

* User adoption of a software system is key for its success and ROI (return of investment). Make sure your users are happy and kept informed throughout your project delivery.

* Focus on User Adoption in your design more than just delivering as many functionalities as you can. For example, go an extra mile to deliver a user friendly interface with less number of clicks and actions required to get to where you want. This is more important than delivery more functionality and features at the expense of usability and user adoption.

* Capture ALL requirements whether or not they can be included in your current development and build phase. These can be useful to drive your next phase design and requirements work.

* While capturing all requirements, make sure you inform the business stakeholders if you believe some requirements cannot be delivered in the current phase either because you ran out of time or because the request is too complicated.

* Requirements that require complex design and implementation should be reviewed thoroughly and potentially pushed back to the business to evaluate its benefit. It is always bad to deliver 80% of functionality in 20% of the time and the remaining 20% of complex requirements are delivered in the remaining 80% of the project time. It’s not the best approach in my view. Explain to the business the benefit of delivering a simpler requirement (instead of the exact complicated requirement) and how you can include many more features if you go for the simpler requirement that takes less time in implementing. As long as the business is aware of this, it’s fine. But don’t just say yes to any complicated not-very useful functionality request that will consume a lot of time and money and cost the customer more.

* Try to avoid big bang implementations as much as you can. Run away from it if it was offered to you. A project that takes 2 years to deliver all in one phase and the business will first see the system 2 years after they said what they want is destined to fail. I’ve seen many projects fail because of this big bang (surprise) delivery. Split your implementation to smaller phases where the business can see the system and start using it in a frequent roll out approach. Surely, the requirements and business processes agreed today will NOT be the same or stay static over the next two years or so. Hence, make sure you only implement a portion of the requirements in a shorter 6 months phase and then deliver it, get your business users use it and feed back on it, then move on to the next phase. You can start the discussions and even the design of the second phase while the first one is being developed but better not to start the development and build until your first phase is delivered and somehow deemed acceptable by your client and business stakeholders.

I’m sure there is much more to add, so please comment below with any more points or comments on the above points.