Ensuring a successful engagement

Success requires great communication and the right blend of approach and skills

Custom apps are complex initiatives at the best of times. In our industry there are as many failures as successes when it comes to delivering solutions; a topic in general not openly discussed by the industry. Not great odds when you consider the investment you make in time, effort and cost.

So how do we minimise the risks for you, and maintain our long-standing success rate?

Building a successful solution is a combination of experience, expertise, a suitable project and development approach, a good business culture alignment between all parties, a well understood requirement and a lot of effort. Taking short cuts increases the risk of failure.

Our approach is to reduce risk by ensuring that we have a common understanding of all the aforementioned factors between all parties before starting any work. This ensures that the project is properly estimated in effort and costs terms, and expectation by all is clearly defined.​​

Step 1

Step 1 – The initial engagement and assessment (free)

This includes a briefing of requirement, signing of a Non-Disclosure Agreement if required, a discussion on how to deliver the most fitting solution and determine how best to work together.

The outcomes of Step 1 are:

  • Stipulation whether IMSX have the necessary expertise and experience.
    A Yes/No on whether we have the appropriate skill and experience to deliver your solution.
  • The project approach IMSX will use.
    Large organisations often require adherence to a formal approach like PMBOK or Prince 2, a smaller business may not have a preferred approach or experience in this area. IMSX matches the appropriate involvement of our own project manager to oversee and manage the project from an IMSX delivery perspective. If required, we manage aspects of the client’s deliverables as well.
  • The development or configuration approach IMSX will use.
    A number of considerations determine whether we utilise SCRUM, other Agile derivatives, Incremental, Waterfall or RAD. Influencing factors are how well the requirement is defined, how much time you have available to assist us with our queries, whether you want your IT resources involved, any preferences in approach and your contractual requirements.
  • Outcome on business cultural alignment, understanding of requirement and the effort involved.
    A Yes/No from all parties on whether there is alignment on expectation of cost, timeline, quality, effort involvement needed and whether we can work together.

At this stage we would have only had a brief time to understand your organisation and requirement. To achieve a best estimate we rely on our past experiences of similar solutions. Alternatively we consider the complexity of the functionality required or the maturity of the technology area we are developing/ configuring in. The estimate as a result can be out by a large margin; however, it is very useful as a measure for budgetary expectations.

Step 2

Step 2 – Scoping, proof of concept and requirement definition (paid)

It is necessary to have a scope that includes a work breakdown structure, irrespective of the project development or configuration approach used. In doing so, it allows for initial assessment of the necessary number of sprints/iterations/phases/cycles and the project steps required to ensure timelines are met, quality is maintained and acceptance testing is achieved.

Depending on the nature of requirement we recommend an initial Proof of Concept that is used as a calibration exercise to assess effort required and timeline.

The definition level of the client requirement is a key factor in selecting the solution delivery approach. If the requirement is loosely defined, SCRUM/AGILE and RAD are good approaches to flush out the requirement detail without losing too much time or effort in wasted development or configuration. Alternatively, if the requirement is well defined, or contractual requirements dictate a set approach, then Waterfall and Incremental approaches are well positioned to deliver signed-off requirements at the right phase or cycle.

The outcomes of Step 2 are:

  • Timelines
  • Understanding of the requirement according to the solution approach used
  • Proof of Concept
  • Cost Estimate
Step 3

Step 3 – Build or configure the solution (paid)

Regardless of which solution approach is used, all development or configuration needs to be put through unit testing and solution testing prior to client handover for user acceptance testing. All solutions need to implement version, source code and change controls. Design, quality requirements, look and feel, scalability, performance requirements, etc. have to be carefully considered to ensure the right solution architecture for your needs and budget.

The outcomes of Step 3 are:

  • The solution delivered for testing according to the solution approach used
  • Test scripts
  • Source code and objects (version and change controlled)
Step 4

Step 4 – Acceptance Testing and Handover (paid)

Acceptance testing ensures the solution meets the need. To determine if the requirements of your specification are met, it is important to test the solution in a pre-production environment in accordance with a number of user test cases. Once acceptance occurs there is a formal process of handover of the solution into a production environment with all the associated configuration, code and installation detail.

The outcomes of Step 4 are:

  • The Solution
  • User Acceptance Test scripts
  • Source code and objects (version and change controlled)
  • Installation scripts, code and guide
Return to Contact Us