Homing In: Confirm the Plan, Technology and Resources

In this, the fifth in Visihain’s series of articles, we will be outlining the key elements of the next stage in the Software Development Life Cycle, SDLC, when you go hard on the plan, the technology, and resources.

At the end of this step you will have committed to the full production development stage.

The Six key Aspects of this Step Are:

  1. Resources confirmed and final cost projection agreed
  2. Hi-fidelity interface created
  3. Project plan finalised and confirmed
  4. System architecture confirmed
  5. Technical specification confirmed
  6. Quality Assurance (‘QA’) plan finalised and confirmed

1. Who and How Much: Resources Confirmed and Final Cost Projection Agreed

The previous steps have led you to a position where you have a reasonably tight estimate of the costed effort required to build and deploy the solution, plus costs associated with hardware & hosting, infrastructure and any 3rd party software components.

You should also be aware by now of what the ongoing support costs are likely to be.

Be prudent and build in contingency. This contingency may be openly agreed with the development team but should be tightly controlled by you. Some wizened old project sponsors might even keep some contingency up their sleeves.

2. Sharpen the Picture: Hi-fidelity Interface Created

At the previous stage, the prototype was build and agreed, with low-fidelity functionality and interfaces.

Now, at this stage, high-fidelity interfaces are created and reviewed.

In particular, any specific issues which were noted at the time of prototype review regarding navigation and the UX should be proven or eliminated.

Interfaces with other systems which enable integration would also be a key concern and these should be clearly proven to work.

3. Perfecting the Plan: Project Plan Finalised and Confirmed

You might have heard the term Gantt Chart. Don’t be fooled – a Gantt chart is not in itself a project plan.

The project manager should have prepared a detailed project plan which addresses any risk issues and includes adequate contingency. Even at this stage, few projects are without any risk at all.

For example, the loss of a key team member could have a significant impact, or timescales could be hit by the release of a buggy piece of 3rd party software.

Gantt charts have a part to play but they are far from being project plans. Beware!

Gannt Chart example

Don’t be misled between a nice looking Gantt Chart and an executable Project Plan.

4. Solidify the Skeleton: System Architecture Confirmed

Any issues about architecture should be eliminated during this stage.

It is possible that the prototype had issues of performance or tested more than one architectural option – for example which specific content management system would be used, perhaps a choice amongst Joomla, Drupal, or WordPress.

5. Crucial Tests: Technical Specification Confirmed

The complete technical specification of the system should now be ready for your approval.

This includes the final screen designs and the functional and non-functional system behavior required. For example, screen and communications response times.

In agile projects, the technical specifications may be written as a series of tests – this saves time and focuses on what is important: software that works. It also saves on documentation overhead and simplifies the build of future enhancements.

6. Quality Assured: QA Plan Finalised and Confirmed

What you have actually been following in this series of articles is, to a certain extent, a quality assurance process – How to Ensure Software Project Success. However, there is clearly a deeper level of detail which needs to be addressed if the software is going to achieve its purpose: it will have to pass a series of tests which realise the specification, as planned in Part 3.

Increasingly, automated software testing is used, but this may require a level of investment which is not appropriate for a one-off project.

When you expect to release multiple upgrades of your application then investment in building test harnesses may be worthwhile considering.

Also, if you are deploying say, a mobile app, to more than one architecture (say Android and iPhone), then much of the testing would be duplicated. The QA plan will need to take account of issues like these.

Users and technical staff (Remember the Stakeholders?) will need to be selected to carry out the final user acceptance testing.

Most application testing will require representative test data – even when your app is just a simple photo library, you will need to upload test images and check for file size limitations, file format types and so on.

Finally, don’t expect perfection.

Be realistic and set reasonable criteria for acceptance of the software. Certainly it should not contain critical defects, but one or two moderate severity defects may be tolerable in the short term provided that there is a clear, credible and timely plan for their rectification.

Final Comments

Your project has already come a long way, and you have eliminated many of the risk issues as it has evolved through the life cycle.

Now, with all the key elements confirmed, you are ready to commit to the main Development phase, when the first full production version will be built and tested. We’ll cover that phase in the next article in the series, continue learning >>> Building a Real Version, The Main Development Phase.