Software development has changed
The three processes of any successful IT project are Think, Build, Run. We’re not calling them ‘stages of a project’ for good reason. ‘Stages’ makes it sound like you move from one stage to the next once the first is complete; that you must do all your thinking before you do any building.
Back in the good old days, when the Waterfall methodology was king, that’s exactly what every good IT development project had to do. Why? Because software was written using inflexible tools and languages that meant correcting problems and making changes was very costly and time consuming. Think punch cards (check this out if you’re too young to know or even care!), then Mainframe text editors (cut and paste – you wish).
But today, software development tools and languages at our disposal allow far more flexibility, meaning there’s no need to stick to the Waterfall method. Agile methodologies are taking over. By ‘agile’ we are referring to a more iterative approach, where by projects can be broken down into any number of think, build, run iterations, or think, build iteration, or build, run etc. etc.
So software development has changed but those 3 process are still key – Think, Build, Run – and they’re baked into the way we work with our clients here at Unity Information Systems.
Think 
No matter what project methodology you’re going to use, some degree of thinking at the very outset is essential for successful project delivery. Agile methodology is never an excuse not to think. How much thinking you do before you start building depends on the project, but at the very least must include:
- Why are we doing this? Seems like an obvious place to start and many project teams know the answer, but not all write it down. Fail to document the why and there’s a risk that the project will forget the answer, and several months / years later can’t work out what the answer is / was / should be.
- Who needs to be involved? Who knows the most about what the project is meant to deliver, whose jobs are going to affected, who is going to take overall responsibility for the project, who’s going to manage it and who’s going to build it? Get the right project team together and assign clear roles and responsibilities from the start.
- What is the system going to do? This covers scope, high level requirements, detailed business requirements, user experience, and the debate about whether systems design is part of business requirements and system build. Define the system scope as soon as possible. Only when the scope’s defined can you work out timescales and project costs (which is really what everyone wants to know as soon as possible). Agreeing timescales and costs that everyone is happy with (including contingency / variation) is a key goal of the ‘Think’ phase. The more ‘nailed down’ you want your projects time/costs, the more thinking you’ll need to do.
- How are we going to deliver this project? What tools and skills are required? What training is needed? Where will the system live and who will look after it?
In our experience all of this thinking is best documented and agreed in a ‘Project Definition report’ – the project contract between all parties.
Build
Do the developers now sit in a darkened room and churn out the system? They could but it’s not the best way of doing things. Collaboration and communication are the vital to successful IT development projects.
Requirements change, requirements are misinterpreted, or are missing key details – it’s inevitable. So regular meetings, phone calls, WebEx’s, demos etc. between the development team and key stakeholders are essential if you want the build to stay on track.
Make sure key personnel are available to make decisions or take on the tasks to address any issues arising. If the development team is left to build ‘in the dark’ then you’re introducing a big risk to the project.
Don’t forget to plan your testing! It’s always left until the end and always the task that gets squeezed when project deadlines loom, but it is so vital. All bespoke-built software will initially have some defects in, be it from misinterpreted requirements, missed scenarios, or just plain omissions from the code. The important thing is to find these as soon as possible, when the cost of addressing them is at its lowest. There are plenty of tools to help with QA, from built-in unit testing in the code, defect tracking tools, test planning and execution and many more. Use them.
Run
Your new system is built and tested and ready to be unleashed. Have you planned how you’re going to implement this change within your organisation?
People don’t like change, it’s a fact. And if you don’t get this right you could end up with a lot of people on too quick to shoot down your new system – project assassins. Get it right though, and people will embrace the change as they can see how it will improve the way they work, removing gripes about their jobs that they’ve come to accept- your project ambassadors. Get some ambassadors onboard early and motivate them to spread the word.
Have you thought about the technical challenge of implementing the system? Do you need to migrate data from an old system? Do you need to get the IT department to build servers, provide network connectivity? Who supports the system once it’s live? Do they have all the necessary access to the system so they can support it?
To Conclude
Bespoke software projects can seem a daunting task to those who are new to it. But it needn’t be if you break it down into simple, well defined stages. We like to “Think, Build, Run”, and I’m sure there are many other similar terms, but whatever you call them, keeping it simple is the key.
