How To Organise A Successful Software Project

Before you get in over your head, make sure that you consider the different elements involved in creating your unique software product. What kind of process is best going to support your final vision? You can work in small stages that make it possible to release pieces of a larger concept. This is logical to help manage the cost and to raise future capital. You may find that operating as one large planning team with less flexibility but more concrete goals is a better way to work. Whether the issue is interaction between a project leader and the coders, or finding a way to balance progress with procedure, you’ll get some great ideas for what might work best for your development by watching this video.

Video Transcript:

What makes the perfect software project?

We’ve now talked through Kanban, we’ve talked through waste and we’ve talked through software development methodologies. I’m bringing it back now to the perfect software project.

What are some attributes of a perfect project from a number of different directions?

First of all it is a science, it is something that can be measured. It is something that you can measure, change and then measure again and discover whether or not the change you have made is a good one.

The project team

First of all you’re going to have a team. I’m going to split the team part into two parts. There is us and there is the client.

What is needed from our team?

  • Friendly and accommodating. I don’t want to have someone on my team who is not friendly and accommodating. There are times when things go wrong. There are times when difficult conversations need to occur. One of the things that is vital when picking your software developer is making sure they are someone you can talk to. If you feel in any way, oh, I don’t want to have to call them again, it’s a bad relationship that you want to be careful of. That lowers the likelihood that you’re going to be able to bring up an important issue.
  • They need to be empowered to make decisions and raise issues. Making decisions is something you want to make sure it goes through all the appropriate checks and everyone is in agreement that the decision should be made. But you don’t want people who are just doing drone work. If they see something wrong, you don’t want them saying, it’s what’s written there, and tapping away, doing the wrong thing. You want them feeling comfortable enough to give you a call and say, I think if we did this slightly differently it would save a heap of money or save a heap of time.
  • Flexible and non dogmatic. This is the same type of thing again. You don’t want someone who says, I’m not going to do it that way. I’m not going to do it the way you wanted because of a personal decision, I hate waterfall, I’m not going to work on that software project. You want people who will maybe have the argument around the benefits and cons, but ultimately will work with the team and with the process.
  • You want them solution-driven. You want them to be thinking about the best way to achieve the outcome. Again, if they see a better way of doing something, you want them to be raising that.
  • You want them to have a high degree of ownership. You want them to be able to say, this was our bad. We did the wrong thing. We didn’t follow the process, we did something wrong, we’ve released a bug that should have been picked up, something like that. You want them to not be afraid of that. But at the same time you need to make sure that the conversations are nice enough that you don’t scare them off from doing that. Ownership is a thing that should be encouraged.

Then there is the client.

What do we want from a client?

  • We want a client who is open to discussion. We want to evolve the process and the product and get the best result. The only way we can do that is by having a discussion and communication around it.
  • We want them engaged in the process. As I’ve said, some of our best projects are ones where we are talking to our clients frequently and really have an open and engaged relationship with them. Andy, who is going to speak to you later, had one of his BAs working in our office four days a week for somewhere in the region of nine months. That was what the software project required. It required really deep engagement from their side. We were dealing with complex legal work that if you were trying to document it or deal with it on an hour a week phone call, it just wouldn’t have worked. So engagement is really important.
  • They need to be motivated to succeed in their market. That means making the changes that are required to succeed, not being inflexible as to what it is they’re trying to build.
  • Ideally a single point of contact and decision making is best. If you have to refer to nine different people to get an answer on a thing, or if a committee needs to meet every time a decision needs to be made, this slows your process down. This is a benefit of waterfall. You only need to have those conversations once. If you’re trying to do things in an agile fashion, every time you raise an issue and have to go through that whole process, it can be a nightmare.
  • They need to be open to the idea of being wrong. That is, open to the concept that what I was going to build isn’t the right thing. I’m happy to be flexible.

Finally we’ve got the process.

What’s needed in a process?

  • You need a concrete starting point. Just get something down on paper. Work with the concept that you’re going to evolve the system. That is probably the only thing that I am dead set against with waterfall. That is the concept that nothing will change. I like being able to see a problem and address it. But you need to have a concrete starting point so you can start having that discussion.
  • You need agreement from all parties. Even if it requires a bit of debate and not everyone gets what everyone wants, you need everyone to own the process and realise that everyone has decided and agreed that’s the way things are going to be run. They need to own the good and bad from that.
  • You need to know where the dials are. You need to know what you can change and, when you change it, what does it do? For example, if you get more people onto the project, you might get a bit of a benefit on how fast things are going, but there is also an increased overhead of having to keep multiple people engaged. The larger your team scales, the more you lose in other areas. But you need to know where those dials are and how to tweak them and what you can get out of them.
  • You need visibility. That is by far the most important one because everything else flows out of that. If you have visibility of your process, then you gain a whole lot of power that you didn’t previously have.

Summing up

Quickly running through what we’ve learned.

We’ve talked through:

  • Waste. We’ve looked at some of the common types of waste that we find in software development and how to recognise and tackle them in a number of cases. Waste is a topic that I just love so if you catch me around in the rest of the day I will happily talk about any form of waste and the addressing of it. It’s a passion.
  • Methodologies. We’ve explored a number of methodologies and their strengths and weaknesses. I hope I’ve left you with the idea that they are really just a vast toolkit that people have decided to take a few of and put a label on. There are many options. Learn about as many as you can. Learn about ones that sound like they’re going to be distasteful. You might find a little nugget in there that you can take and use to evolve your later processes.
  • Kanban. We talked through what a Kanban board is and how Kanban practices can enhance anything. Think of any internal system you have and think about the benefits from adding some visibility to that. Any process made visible suddenly becomes a lot easier to improve.

This is one section from a longer presentation. Go to the:

previous section

beginning section

Understanding a range of different procedural techniques can help you consider the right way to organise your software development project. This is a specialised area, and not a one-size-fits-all scenario. From an agile technique to Kanban, the possibilities are nearly endless. You can even combine techniques for efficiency and customised workflow. Whatever options make the best concept for your software projects, you can keep all of these techniques in mind to help you reach your best potential.

Do you have a software project that needs the right team, and you don’t know the first step to take? Get in touch with us today.