3. Methodologies

There are a number of different ways that an IT project can be run and they usually follow a methodology, which one depends on the type of project and also what is the standard within your company. Methodologies are in fact a set of defined processes and principles that a project follows in order to deliver something that the business needs.

There are three main methodologies used to run IT projects, although there are many more around based on these three.

The Waterfall Model

This used to be the most common method for delivering projects and was taken from the manufacturing sector. The principles within the waterfall model is that the project will move through each stage sequentially and the new stage cannot start until the end product from the earlier stage has been completed. This means that what the customer requested/wants will only be delivered at the final stage of the project.

Key points to note about the waterfall model

• It uses the big bang approach to delivering the solution to the customer.
• The customer is not involved all the stages.
• Each stage tends to work within their own silo and produce a stage output, such as a requirements document is the output of the analysis phase. This is then handed over to a team of software architects or designers for them to design the system from the collected requirements. This in turn, would produce a design blueprint that at the end of the stage is handed over to a development team who will then code the system from the design and so on.
• Once a stage has been completed it is common for that team to move onto a different project. This therefore provides additional pressure each stage to ensure that the outputs of the stage are well documented and correct.
• If at a later stage it becomes clear that a mistake was made in an earlier part of the project, it will be dealt with as a change request that will happen at the end of the project.
• Waterfall model is best suited for IT projects that are repeatable and are low risk, such as software or hardware upgrades. Within these types of projects there are known steps that the project needs execute, but also a few unknowns due to new hardware of software.

RUP Model

RUP takes a progressive approach in developing IT solutions, which has been shown in practice to be far more effective than the traditional, serial waterfall model. Although this method has a sequential element to it due to there being four distinct stages, it also takes advantage of iterative principles by delivering outputs via incremental releases throughout the project’s life, whilst following proven best practices, such as Stop/Go decisions at the end of each stage.

The four phases RUP projects follow are:

• Inception phase- Within this phase the project’s business case is defined and work is carried to determine if the project is worth doing or possible. It concentrates on what the project scope is, the requirements and puts plans in place for who is required and how the project will be run.
• Elaboration phase - This phase will specify the requirements in more detail and prove the architecture for the system. This is carried out by taking some of the higher risk requirements and doing analysis, design, build, testing on them. This is sometimes confused with prototyping, however the end products that are developed in this phase will be used within the end solution and therefore are not just proof of concept.
• Construction phase- The focus of the construction phase is to develop the system to the point where it is ready for deployment. If necessary, early releases of the system are deployed, either internally or externally, to obtain user feedback. It is common to have multiple iterations within this phase. This allows the customer to see the progression of the end product.
• Transition Phase - This phase is about delivering the system into production. It concentrates on system testing and user testing and any final adjustments are be based on user feedback, relating to usability or installation issues. Alongside this, training of end users, support, and operations staff is done.

Looking at the phases you may be wondering how RUP is different to waterfall; on the surface it looks like the only difference is less phases or stages. The power of RUP and where it differs is, that even though there are set phases, skills and people do not work in silos. Throughout each phase a number of skill sets will being working together even in the early inception stage and they are referred to as the nine disciplines of RUP:

• Business Modelling - The goal is to understand the business of the organisation, usually confined to the scope of the business that is relevant to the solution being developed.
• Requirements - To identify, document, and agree upon the scope of what is and what is not to be built. This information is used by analysts, designers, and developers to build the system, in addition by testers to verify the system, and by the project manager to plan and manage the project, so getting it clearly defined is key.
• Analysis and Design - To analyse the requirements and design a solution to be implemented based on the requirements, constraints and any relevant standards and guidelines.
• Implementation - To transform the design into executable code and to carry out a basic level of testing, in particular unit testing.
• Test - To perform an objective evaluation to ensure quality. This includes finding defects, validating that system works as designed, and verifying that the requirements have been met.
• Deployment - To plan for the delivery of the system and to execute the plan to make the system available to end users.
• Configuration and Change Management - To manage access to the projects outputs. This includes not only tracking versions over time, but also controlling and managing changes to them.
• Project Management - To direct the activities that take place on the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc…), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget.
• Environment - To support the rest of the effort in terms in ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed.

Key points to note about the RUP model

• It is does have sequential phases.
• It does follow defined processes, such as end of phase stop/go decisions.
• It groups work into smaller iterative work packages.
• It is collaborative. The team needs to work together and are involved for most, if not all, of the project.
• Documentation is still produced, but it is continuously improved when more is known at each phase.
• It needs to incorporate the nine disciplines in each phase and iteration.
• By selecting the high risk requirements first means that if these prove to be too difficult then decisions on whether the project is viable or if more people are needed on the team can be made a lot earlier in the project.
• Most IT projects that say they use Waterfall, but have iterative deployments, should be using RUP instead.

The Agile model

Although the concept of agile has been around for some time now, it seems to have taken a while for companies to adopt it. One of the challenges that agile has faced is that it changes the way IT projects are delivered and also how project teams work together, therefore for some companies who are used to a more regimented approach agile seems high risk and a lot of change.

Agile has been seen as an approach that is organic and unstructured, but this is not true. Good agile projects do have structure and processes, but how the solution is planned and delivered is more flexible.

Looking at the agile diagram you will notice that agile projects do not have phases or stages assigned to them as standard. What agile has is sprints, what you do in each sprint is defined by the customer and what they believe is the most important elements the solution must deliver.

Like within the RUP model a good agile team needs to have expertise for all of the skill sets for the duration of the project, in agile projects the team are normally working on one project at a time and can cover multiple roles if not fully utilised. In agile rather than separating out the analysis, design, build, test etc… these are done at the same time during a defined sprint and at the end of the sprint element of the solution will be ready to deliver into production for the business to test or start using.

Key points to note about the agile model

• Agile projects do have processes and principles.
• They are structured and they do have documentation.
• They include a number of sprints that include a certain amount of requirements.
• Sprints are time-boxed to typically 2 - 6 weeks.
• At the end of the sprint completed requirements are deployed for the users to use.
• Uncompleted requirements are put pack on the pile of remaining work to complete at a later date in the project, this is commonly called the backlog.
• Sprints should never be extended in duration in order to finish something.
• Sprints should be of a set time that is constant throughout the project.
• Planning and business requirement gathering is done before the sprints are planned.
• The customer is part of the project team and has an important role in deciding what requirements are to be delivered first and are involved in testing.
• Sprints are typically made up of 3 parts, start - planning what is to be in the sprint, realise - the implementation of the tasks and evaluate time to reflect on what was completed, what is outstanding, what went well and what did we learn.
• By having the customer involved and short deployments allows the team to respond effectively to change.