How to Adopt a Project Methodology...The Easy Way

Let me tell you something that might make you feel great.... ??

If you've already realised you need a project methodology in your business or team then you're already winning!

But now you're thinking about which suits my needs best?! ????♂?

Well, what if I was to tell you that you can just make your own that completely fits your business needs, would that make it much easier to...

1) Decide....

and 2) implement...

? ??

This might just be your lucky day then if you answered yes to both of those, because you can do JUST that. ??

In this newsletter we'll talk about agile and waterfall project methodologies, and be cherry-picking bits out of those that you can adopt easily, but nevertheless there are more things out there that you can utilise when it comes to strict project methodologies.

NOTE HERE: Before we get stuck in, this is for the project police, please don't come at me for butchering methodologies, I'm sorry if I get a definition wrong, but this is me trying to make ops and project methodologies appeal to the masses by making it relatable and, most importantly, easy. ????

TL;DR:

Use:

Scrums (Stand ups) and retrospectives at the very very least. Accept change and manage it well. Scope projects, whatever it is. Don't use waterfall. Good day.

Agile Project Methodology

Exactly what it says on the tin, it's agile.

Using an iterative approach to delivering projects, expect to see project broken down into phases of a delivery, encourage continuous improvement through retrospectives, use people's feedback and overall promote flexibility within a project to deliver the best possible outcome. Agile can be affiliated mostly with product development, however it's principles can be put across any project like we'll show you further down.

Within agile, you will set out with a goal, but as you go that goal can change, as long as you're getting sign off from your stakeholders and stick within budget.

A scope is always the best place to start, writing down what is required, what success looks like, how you'll get there, when you need it done by, and who will be involved and to what capacity (what,what,how,when,who...of course).

We won't go into too much detail here, many many books do that, such as:

• The Lean Startup
• Project Management the Agile Way
• The Phoenix Project

Agile methodologies also have some key features within them which we'll explore later as we cherry pick the very best parts of what can be used quickly.

These are:

Scrum: Many books are written and many qualifications are given for Scrum, but for us at Opticks. it's a stand up where you say what you did yesterday, what you're doing today, and if you have any blockers. And in it's simplest terms, that's how you can use it too.

Feature Driven Dev: More on the product side, but allow your development of your product to be drive by the features your clients need or want, team this up with the feedback you'll be getting through agile and you've got a winning way forwards.

Incorporate Customer Feedback: Ah like magic we talk about it and it appears. Agile promotes asking customers, clients, your team for feedback, usually through a retrospective at the end but throughout a project is healthy too. Be careful of scope creep, but also be aware you want to deliver, so pop in a change request and managed correctly this can be powerful.

Promote Flexibility: Change is scary...if you don't manage it well. Agile and flexibility go hand in hand, so be able to pivot and adapt within any project.

Lean Software Development: Keeping things lean in agile is key, whether that's uncomplicated, smaller teams, or keeping a good pace through unit testing.

Parallelisism: Yep, just made up a word that means that within agile, things are often done in parallel where possible to speed things up, tested together or alongside each other if they stand independently.

There are drawbacks...

Scope Creep: I eluded to it, but it really can derail you and throw your budget out if you don't manage change correctly.

No Clear End: If you're forever iterating, is there an end to the project? Although, is it a bad thing if there's not? Leave that one up to you.

Demands more time and energy: As a PM, you've got to be more active and 'on the ball' with agile.

All round more difficult: More action, less defined, less clear, it's tough going with agile.

Silly Example of an Agile Project

Project name: Me making my wife a tea

Stakeholders: My Wife

Project Manager: Me

Scope: English Breakfast Tea please, milk, no sugar.

An example of how agile methodology delivers here:

We had an issue where the kettle wasn't working, so in our scrum, I mentioned a blocker that the kettle wasn't working, however my wife correctly pointed out I could use the hob to heat up water. The project then changed to me using the hob to heat up water to make the tea.

The client (my wife) then asked whilst I was halfway through testing the method of heating the water if she could have a mint tea instead of English Breakfast. We put in a Change Request, amended the sprint to reflect the change and updated our timeline due to not having to go to the fridge to get the milk.

We unit tested that the water was ready to make the tea by testing the temperature with a thermometer, and proceeded to make the tea.

We delivered the Mint Tea. But the mug was not the pretty one with the flowers on it.

In our retrospective we discussed that the tea was good, however the mug was wrong, so next time we'll make the tea with the correct mug.

Waterfall Project Methodology

Note: I hate waterfall methodologies so this will be biased.

Waterfall projects are often associated with old-school big business. Very linear and rigid in the way they are executed that involves each stage of a project being completed as you go.

This methodology works at it's very best when the requirements are defined right at the start of a project and nothing SHOULD change...

The benefits are that is makes it easier to manage and saves time therefore money across a project, it's super easy to plan.

The drawbacks are that life and business often aren't like that at all.

Why's it called waterfall? because each stage of the project cascades into the next, nothing's done in parallel, and things aren't tested until right at the very end.

Again, but more apparent, scope is SUPER important here, as what you define is what's getting delivered. You can still have scrums but nothing really can be changed. The feedback loops aren't really there with the client either to change a project mid-way through. No change = easier to manage, but may not be ideal if there is an actual change needed.

I apologise. I've been scathing. I've just never ever seen it work ?? Please correct me if I'm wrong.

Silly Example of an Waterfall Project

Project name: Me making my wife a tea

Stakeholders: My Wife

Project Manager: Me

Scope: English Breakfast Tea please, milk, no sugar.

An example of how waterfall methodology delivers here:

Scope is defined to make the tea, so here we go.

Firstly I'll boil the kettle. However it doesn't work so I'm a bit stuck...

I've bought a new kettle so will now boil the kettle.

I've put the water in the cup. Let the tea bag brew and now putting the milk in.

Done.

Delivered the tea.

It turns out that whilst at the shop buying a new kettle, 3 hours passed and now it's too late for a caffeinated tea so my wife wants a mint tea to help her digest her dinner.

I need a new project to go and make the mint tea. I've wasted the English Breakfast Tea.

Again, I apologise for being so biased, but it's the way I see it.

Now let's implement the good bits of what we've learnt from these two methodologies very very easily:

Scrums:

Implement scrums as 'Stand Ups', have them as a meeting at a frequency that suits you and your team (or just you on your own still works!, just record your notes).

Don't want another meeting? No worries, have a process where you write on your comms channel each day:

1) What did I do yesterday?

2) What will I do today?

3) What blockers do I have?

These three questions apply if it's a meeting, just you reflecting or a comms channel post.

Retrospectives:

Again, super simple to implement.

After every project, day, week, month, meeting, whatever you like, have a look at it and get a feedback loop from whoever was involved. Ask the same four questions:

1) What went will?

2) What didn't go well?

3) What can we improve?

4) What will we do differently next time?

Do this as a discussion or interactive whiteboard and as something that's collaborative. Take everyone's feedback on board and action what you will do differently.

Keep doing this and you'll have the perfect formula for delivery for you or your team.