Monday November 2, 2009
Software development projects, especially bespoke solutions, are notoriously high risk and can end up running over budget and way past the project deadline which is why there is a need for a strong process that works time and time again. Unfortunately the Government's many IT projects are often an exemplar of what can go wrong.
People, process and management
The key ingredients to ensure that any project will be completed on time and on budget are people, process and management.
The most valuable resource to any development project are the actual people that carry out the work, and to ensure all the other elements fall into place you need to obtain a team of developers, programmers and project managers that show the following characteristics:
- High quality, very talented
- Experienced and qualified
- Work quickly and precisely
- Very supportive, strength in depth, team work
- Excellent client service skills and the ability to deliver.
Once these core strengths/traits are the backbone of a development team then it is already halfway there to ensure successful outcomes. But to obtain success then a precise and quality process needs to be applied to enable milestone to be achieved and the roll out of the various project phases before general release.
Behind a process there are varying methodologies that can be adapted to fit a system that suit the particular development team, or they can follow industry specific standards such as RAD (Rapid Application Development), or RUP (Rational Unified Process). Neither methodology is better than each other but they do outline common pathways to follow.
The main principles to a successful process are that it always firstly needs a set of "Requirements". These are "full breadth" business needs, i.e. encompassing all areas, but not necessarily "full depth". Requirements should cover both functional and non functional (e.g. security, audit, accessibility, performance) aspects.
The following points outline the characteristics that are sought after:
- Easy to read and understand by categorising requirements into meaningful/logical groups
- They are consistently at the right level, and not "spikey" (some areas covered more thoroughly than others, or worse still inappropriately technical in some areas)
- Each Requirement records important cross reference information: the source, priority, and also whether it is a new/changed, or existing requirement
- Uses nomenclature or annotation to differentiate between Mandatory and Wish List requirements
- Coverage of Non-functional requirements - these should not be underestimated, as they are often forgotten, or partially represented, and can be often the downfall of a Project. Non-functional requirements include issues such as the required performance of the software, what screen resolution it should work in and whether it needs to support multiple languages or character sets.
The second principle to be included in the process is the Specification which is absolutely necessary. Use Cases are one widely adopted approach to capturing a detailed spec, and it is strongly argued that you cannot develop effectively without them. The Use Cases and Supplementary Specifications are written against a Requirements document to capture much more depth on the functional, and non-functional requirements respectively. Use Cases are an excellent medium to capture and review specifications with the business users/project team and development team. Once signed-off the development team can proceed to design, and develop the system. A good notion to work to when devising a specification is "If it's not in the specification, then it can't be developed." And if you're outsourcing a project, if it's not in the spec then the supplier can justly not deliver that aspect of the solution.
Investing significant amount of time into the design ensures that solutions that are typically resilient, robust, scalable, more supportable, and extensible. In common with any problem that has to be project managed, risk management is key to ensure that software investment works. Identify risks, develop mitigation strategies, and monitor risks as all projects have risks that need managing. A lot of process is geared around lowering the risks on projects, enabling the team to proceed confidently, and with pace. Developing in iterations, i.e. carry out cycles of development/technical testing/user testing, offers the following advantages:
- Focuses the team's effort on delivery
- Proves the deployment process
- Proves the workings of the system in a near live environment
- Enables client feedback early in the process
- The business/project team sees demonstrable deliverables sooner
Reduces risk by giving the Project Manager earlier more frequent milestones to measure against.
Breaking a project into iterations also allows the use of prototyping which becomes a very important element to ensure software investment is not wasted and the milestones are on track to being reached. Without prototyping most projects would more than likely end in failure, there are essentially 3 types of prototyping which are:
- Pre-contract ("wow") - These are created to show the abilities of the technical team, typically in website design/creative thinking, and hopefully provide some "wow" factor.
- Requirements stage ("light") - Again an element of proving abilities and competence, but more aligned to actual requirements.
- Use Case stage ("full") - Most prototyping is done at the Use Case stage, and complement the words with a picture. Incredibly important to agree the system framework at the start of the development project.
Typically the following aspects are demonstrated during prototyping:
- Look and Feel (Aesthetics)
- Key screens, new screens, or types of screens (e.g. Search, and List View)
- The early stabilisation of the system "framework" is key.
Data migration is generally carried out towards the end of the project, but some project teams look to complete data migration from the source/legacy system at the start of the development stage. By developing a repeatable data migration routine which can be re-run at any time the project gets the advantage of developing and testing using real data - this makes testing a lot easier and provides confidence for go-live. It also tends to help increase acceptance and adoption of the new software by ordinary users as they see data they recognise in the new system.
The whole approach from specification to go-live is geared around making the implementation as smooth as possible, and can be achieved by following a few key steps throughout the process. At the start of a project agreement is required on how implementation may look - this provides focus on the final delivery, plus enables the management of expectations. Data migration is completed at the start of the project; hence all testing is completed against real data. This increases the accuracy of tests, and provides confidence for go-live. Confidence in the system, and use of live data, creates an air of familiarity with the deployment process, and ultimately go-live is seen to be another deployment.
Evidently the requirements that are submitted and developed against at the start may not necessarily be those that end up being deployed due to changes in direction and needs of the business that are discovered during the process. A common sense approach should be adopted as it is inevitable that changes will occur during the development, therefore communications should be open between business and project team about changes (both + and -), and the importance of having a strict change control regime to protect project timescales and budget.
Making a software project work needs a project manager to apply good governance, structure and process from the start. The 3 key attributes of People, Process and Project Management should be in place and are overall accountable for success.