If you hear or are involved in a conversation like this, then the organisation you work for doesn’t have a clue about effectively delivering software. Just saying…

+++++++++++++++++++++++

‘The first thing we need you to do is to spend time doing the detailed functional analysis.’

‘Sure. What’s the most important feature?’

‘All of it’

‘Well if you had to pick one thing for me to focus on first what would it be?’

‘All of it’

‘OK, what about the business value, which one has the biggest impact to the business?’

‘I’m not sure, but we need to do the analysis on all of it, document it all, get it signed off as a whole then we can give it to the developers. They can work out what to do first.’

‘We could do that, but that will take a while and no development can start until after all the analysis has been done.’

‘Yes.’

‘And you are ok with that?’

‘Yes. That’s what we do here.’

‘And you would be ok with the developers choosing which parts to build first?’

‘Yes. I don’t care what they do first because it all needs to be delivered together’

‘What about the stakeholders – what do they want first?’

‘All of it’

‘Have we actually asked them to prioritise the features?’

‘No – why would we?’

‘It’s just a thought but maybe they would prefer to get half of the functionality and those of highest value in 3 months, rather than all of the functionality in 6 months?’

‘That wouldn’t work. According to the plan it’s going to take 4 months just to complete the full analysis.’

‘I see. Out of interest, what is that estimate based on?’

‘It feels about right given the size of the project. If it takes less that’s great, but it can’t take longer.’

‘But what if the plan is wrong?’

‘It’s not’

‘Well what if we find out during the analysis that there are other items of scope that have not yet been considered or if the people in the business come up with a new idea and want us to do things differently?’

‘Then they will have to raise a change request and we will have to spend time doing the analysis before taking it to the working group, and if they agree then we take it to the steering group, and if they agree then we need to update the documentation and re-issue for sign off.’

‘Wow – that sounds pretty heavy and like that would slow things down.’

‘That’s what we do here. But if the business doesn’t know what they want up front then what do they expect?’

‘How long would that take?’

‘It’s not too bad. Normally this could get turned around in 3-4 weeks.’

‘Do you mean days?’

‘No. I mean weeks.’

‘Fuck.’

+++++++++++++++++++++++++++++++++++

Sound familiar? This unfortunately is completely normal practise in large organisations.

From being involved in IT projects using waterfall methodology for around10 years I was not exposed to anything different so just assumed this was what everyone did, but I want you to know that there is a different way to do things when it comes to running IT projects.

A couple of years ago my working life changed as I started to experience something that I wasn’t used to. Something that I’d only fleetingly been aware of at work previously. Enjoyment. I know, CRAZY – right?

I think this came from actually believing that the project I was working on was focused on trying to do the right thing for the company (and more importantly customers) in the most efficient way possible. What a novel idea…

Imagine no longer being limited to a specific role as the cross-functional team you’re part of are focused on delivering what the business wants, small pieces at a time, in the order of highest value first.

Imagine being in a place where detailed analysis still needed to take place, but you don’t need to complete the analysis on 100 requirements before passing the whole set over to the developers. Where the attitude is more – ‘Got 10 requirements documented? Great. Know which 3 of those are the most important? Then let’s get started on those. Today.’

A place where you are a specialist in your area for the team, but the focus on working together was more important than any individual.

Sounds nice doesn’t it? Hopefully you can see why I enjoyed it.

Obviously nothing runs perfectly, and the team I was part of did not always succeed, but we certainly got a lot more delivered than I was used to, and in less time than it had taken in the past.

Changing an organisations approach and mentality to the way they plan, develop and release IT projects is really bloody difficult, especially without buy in from stakeholders and business leads, but luckily the tide seems to be turning and an iterative approach to projects is becoming more common place these days. Well, certainly the desire to try and do things differently seems to be more evident.

I’m probably late to the party on this one, but if you are interested in learning about methods different to the conversation above or have heard words like ‘scrum’ or ‘agile’ and want to understand them better, then here are a few useful resources:

A web site: http://agilemanifesto.org/

A free PDF: http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf

A book recommendation: http://www.amazon.co.uk/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s=books&ie=UTF8&qid=1384883793&sr=1-1&keywords=extreme+programming

There is no one size fits all approach to running a successful IT project. But my point is simply that there are always options, and some are definitely better than others. We should never just settle for how things have been done in the past, but rather we should be looking at what we can do to improve. Always.

Enjoy.

IT-Project

Leave a Reply

Your email address will not be published. Required fields are marked *