Let’s explore some different project methodologies.

Start by watching this YouTube video on the difference between the iterative, incremental, and agile approaches to projects (Duration: 6m 31s). | Link |

Depending on the approach your organisation or your client is using, the requirements from you as a data analyst can vary.

We can divide project methodologies into two broad categories – linear models and agile models.

Linear models

• In Linear models, the development of the app or website follows a fixed sequence
• There is a high degree of control and accountability
• A full specification of requirements is needed at the start of the project
• Linear approaches can be Inflexible
• They are not suited for large development projects (where requirements may change)

Examples of Linear Models:

• Waterfall
• PRINCE2 (Projects in Controlled Environments)

Agile models

• Development of the app or website follows a cycle of mini projects (called “sprints”)
• They rely on teamwork, collaboration and speed
• They are responsive to environmental changes and adapt easily to new requirements
• They are highly flexible
• They are commonly used in software development projects

Examples of Agile models:

• Scrum
• DSDM
• XP Agile

Linear model example: Waterfall

A Waterfall Project is a good example of a Linear Model.  When proposing a Waterfall Project, there are important considerations:

• What is the impact on the later phases if one of the earlier phases runs late?
• What happens if you discover more requirements in a later phase that you hadn’t considered?
• How can the project respond to changes in the external environment, for example, unforeseen lockdown?

Linear cycle

Let’s work our way through this example of a linear project:

On top, you will find the product life cycle, the product as we know is the outcome of a project and it ends when the product is not used anymore.

We then see the extended project life cycle, which includes the time of producing the product during a project and ends when all the benefits have been achieved.

Then we have the project life cycle, which is the time from conception until handover and closure of the project. This ends when the project ends, and the product has been handed over to the client.

You see that we start with the concept phase, your role as a data analyst typically consists of doing research and creating high-level insights needed to see if a project is viable or not.

At the gate review, your project (if it passes review) will move forwards into the definition phase. Here, the project plan, timescales, budgets, benefits and the scope will be defined.  A further gate review will determine if the project goes ahead. Your role as a data analyst might change here, as in this phase a more in-depth analysis might be required.

In the development phase, the product is being built, tested and ultimately delivered to the client based on the acceptance criteria that were determined at the beginning of the project. The clients will have to sign off a project that has been accepted, and then the project officially ends. In the extended project life cycle, the benefit still needs to be reaped. Once that has been achieved fully, the product life cycle will end.

In the following diagram, we can see in more detail the tasks that are performed in each phase of the linear project life cycle. 

At the end of each phase, an outcome is produced. 

• A Business Case at the end of the Concept phase, to determine if the project is viable.
• A Project Management Plan at the Definition phase, to set out actions.
• Deliverables are produced at the end of the Development phase.
• Ultimately, at the end of the project (Handover & Close Out) the Output has been achieved.

The extended life cycle has a fifth stage: Benefits Realisation.

Every project must achieve the desired benefits, hence there is a stage where we measure the benefits that were identified at the start of the project.

This is important because if you only measure the success of the project against the criteria that the products had to achieve, you might be spending money, time and resources on projects but never realising the intended benefits.

Benefits realisation is always split up over different timelines. For example: when you create a piece of software that should make order taking more efficient, the staff using the software need training, and they need to acclimatise before you can measure the efficiency of the software. So even if the software was delivered meeting all the software requirements, the benefits might be achieved over a longer time.  Only after the delivered solution is embedded in the organisation can the success of the project on all measures (technical, efficiency etc.) be assessed.

Software Development Life Cycle (SDLC)

Here is a typical example of a well-defined software development life cycle. Being thorough at each phase of the project is critical to the success of the solution.

Requirement gathering and analysis

• Hold meetings with key stakeholders to determine their needs.
• Analyse stakeholders’ requirements to determine viability.
• Create a Requirement Specification document to guide the next phase.

Design

• Web designers and system designers propose how to meet requirements.
• Involves designing user interfaces and exploring hardware options.
• Designs need to be signed off by the project manager and key stakeholders.

Implementation or coding

• Developers write code for the website or app based on the approved design.
• Work is divided into units or modules.
• Typically, the longest phase of the SDLC.

Testing

• Code is tested against requirements gathered during the first phase.
• Bugs and errors are identified and corrected.

Deployment

• The new website or app is launched.
• This may be a “soft launch” or “beta version” so that users can identify bugs, which will need to be corrected before the final deployment.

Maintenance

• As the new website or app is used, problems may arise periodically.
• Any issues that are identified must be resolved in a timely manner.

Agile Model Example: Scrum

This model works in sprints - where at the end of each sprint a deployment of a deliverable will be delivered before the next sprint starts.

For you to create sprints or do any planning, there is a methodology where you create an overview of all the Major Tasks (PBS), then a breakdown of the work to be done for each of those tasks WBS and have an overview who in the organisation is that could perform the work or will be involved in the project OBS.

Product Breakdown Structure - PBS

A breakdown of all the deliverables (products) that will need to be delivered. A deliverable is a part of the outcome.

 

Work Breakdown Structure - WBS

A breakdown of all the tasks that will need to be completed to deliver the products. (These all start with verbs.)

Organisation Breakdown Structure - OBS

A breakdown of the people in the organisation (resources) that are involved with the project.

Having these breakdowns enables you to monitor all the elements that will contribute to the success of your project.