Best practices for a software project kick off with Steve Baker
- DetailsAbout the talks
- Resources3 Files
Best practices for a software project kick off with Steve Baker
Head of Client Engagement at Future Processing
In this episode, our guest, Steve explains what to take care of when kicking off a software project, be it on your own or with an external IT partner.
Steve and Jarosław discuss items worth consideration during kick off on an example of a past project for Fareshare, a UK national charity fighting hunger and tackling food waste. The project, which involved designing and developing a scalable, bespoke solution for managing surplus food warehouses, was managed by Steve and developed by Future Processing’s engineers.
The episode ends with a summary of 3 things that can and should be done during a project kick off stage to minimise the risk of project failure.
Steve Baker is an independent IT consultant with a vast background in business systems, design, architecture and software development. Steve and his consultancy, Vermillion IT, help companies investigate their processes, assess what kind of systems they need and, if required, run the project to deliver that solution.
Jarosław Granat is Future Processing’s Head of Client Engagement, working to ensure the highest level of services for the company’s clients. He is a graduate of Computer Sciences and Psychology in Business and has worked in IT for the last 10 years.
Jarosław Granat (JG): Hello my name is Jarosław Granat and I’d like to welcome you to this episode of IT Leadership Insights by Future Processing. Kicking off a project is definitely not a stress-free activity. It might get even worse if you do it with an external partner. We are going to discuss today and to show you some examples of how to do it properly. We’ll share some case studies and best advice for you. Together with my brilliant guest who is Steve Baker, a freelance IT consultant and an owner of Vermilion IT company. Hello Steve.
Steve Baker (SB): Thank you very much and thank you for having me.
JG: Steve for those who haven’t seen the previous episode when we talked about whether to buy a software or to build it on its own. Could you please make a short introduction of yourself?
SB: So as you said an independent IT consultant fairly substantial background in software development. But these days I earn my living by working with companies looking at business processes, figuring out what kind of software they need to solve their problems and then if there’s any development arising from that I’ll will run that for them if they want me to.
JG: Sure. Steve, every action that we do, or every project regardless of whether it’s in professional life or in a personal, follow the same path, the way we start it, the kind of results that we can achieve, so the better we start the better results we have and I think this also applies to software development. So I would like to ask you, what elements should be taken into consideration and taken care of when you are starting a project when you are doing a kick-off?
SB: Well, before I came to talk to you, I actually canvassed my colleagues about this. And between us we came up with a kinda like a top three.
SB: So the first one is to have a kick-off. Putting in together a system, its a social activity, as much as a technical activity,
SB: So an important part of having a kick-off meeting is to introduce everybody to everybody, to bring the stakeholders and some end users in to meet the development team and vice versa. What we’re really trying to do is to develop some commitment from both parties to the project. So having a kick-off meeting, probably the number one tip.
JG: Would you say that the kick-off of a project is the kick-off meeting only or is just something more or something in advance?
SB: Well, kick-off is a bit of a process so you’re probably not gonna get all of the kick-off activities done in just one meeting. And in fact one of the things that you need to be careful of so if we brought all these senior stakeholders in and you don’t really want to spend all the time in a kick-off meeting discussing, ’cause developers love to spend hours discussing on what to name their Git branches for example so there is an exercise to capture all the infrastructure development environment set and all that kind of thing but that’s a separate meeting to what I would describe as the project kick-off which is one where you have your stakeholders come in. So anyway first of all have one, secondly make it the opportunity where you get an agreement on what you’re trying to achieve after the project. So let me give you an example. You and your partner decide that you’re gonna go out and you’re gonna have a great night out on Saturday. Now to you, that means having a nice quiet meal in a restaurant,
JG: It does indeed
SB: To them that means going out to a nightclub till four o’clock in the morning. You both agree going out on a Saturday night is a good idea but you have wildly different ideas about what that looks like. And so it’s true in projects. So what you’re trying, what you don’t wanna do, is to, after a kick-off people walk away from that meeting with slightly different ideas about what you’re trying to achieve. Purpose of the meeting is to set that objective and to set that vision of what success looks like. And, frankly, if you haven’t agreed that with the stakeholders first you’re probably not in a position to actually start development yet. Again, what my colleagues all agreed on this is one of the number one you know areas for failure is where there isn’t a common actual agreement on what a successful project looks like.
JG: How do you make sure that you get the proper engagement of all the stakeholders because it sounds brilliant we get everyone, everyone is sharing the same goal, the same objective, everyone knows what is the vision but in reality, I’m not sure what are your experiences but I know that it doesn’t always happen that way so there is a tendency of stakeholders, okay my job here is done, this is what needs to be done, goodbye do it.
SB: Yeah and again people point out that lack of stakeholder engagement is one of the common factors for project failure. It is a difficult one, again this is a social enterprise, but the, trying to get stakeholders to recognise that not only they have a financial investment in this but they are a source of expertise. The development team will have thousands of questions, many of which can only be answered by the stakeholders and they need to be answered in a fairly timely fashion. So again coming back to one of the purposes of the kick-off, is to, I don’t wanna say educate, but bring the stakeholders in and they don’t just have rights but they also have responsibilities here to the project as well and trying to bring that out and get them involved so that they are bought into the project not just for the initial kick-off but through the whole process.
JG: Would you say that there is a kind of difference in the way that you kick-off a project with an external company comparing to the internal project within your company?
SB: Yeah, a lot of things are the same but probably the key differences are, an external company won’t know about your business, or is unlikely to know about your business so when you’re working with an internal development team they’ve probably been working in that business and know what it does. So I do put a bit of time aside to describe what the business does, what the critical success factors are. Maybe bring some flowcharts, diagrams, that sort of thing, just to explain what the business does. Second thing is, you’re gonna be working at distance so as the product owner or project manager, whatever, whatever you’re role is, and your stakeholders are probably not gonna be in the same room as the development team. So there are some things there to work through about how you’re going to work together at distance. The project I did here with FareShare, we started off with a taking Scrum as our process model and that’s quite good ’cause that’s an off the shelf way of, framework from running a project. It’s got defined roles, it’s got defined responsibilities, it’s got defined process. So it meant that even though we were separated at distance we both knew what that process looked like. Now you can and should adapt your process as you go on but taking an off the shelf process framework that your outsource supplier and you can agree on is a pretty good starting point. I think probably the last thing is just say that you’re a customer-supplier relationship.
SB: But when you’re going to that kick-off meeting as the customer, I think you’re on show, I think it’s your opportunity to demonstrate to the supplier that you’re gonna be a good customer. You’re gonna turn up on time. You’re gonna do the things you say you’re gonna do. You’re gonna be good people to work with because that develops confidence in the supplier that you know what you’re doing and confidence in the early stage of the project goes quite a long way.
JG: Why don’t we take a look at some real cases and you mentioned FareShare and this is the project that was done for a British charity preventing food waste. Could you please tell a little bit about that project and how the kick-off of that project was done because it was quite a success.
SB: Well probably should just talk a little bit about what FareShare does. So they distribute for surface route from the supply chain which means they’re taking food in from the supermarket distribution channel and from manufacturers and they’re taking it in large volume and then they share, distribute it out to several thousand partner charities around the UK. So some of the things we did in the kick-off for that, FareShare has quite an unusual business model, not many businesses give things away, so we talked about that, and we did a a bit of a desktop tabletop game model of a day in the life of FareShare so we did a little exercise on the board with some moving post-it notes around and things like that, a little bit of a game, to try to illustrate what that business model was. The other thing that happened there was Future Processing also sent a couple of the team members back to work with FareShare for the day which was good. They got experience of what FareShare was doing on the ground and that was a piece of good practice I’ve taken away from that. That’s very good. The last thing we did on the kick-off I think is possibly a bit unusual but we’d already dealt with systems doing things like FareShare did so we did bring to that kick-off meeting a kind of software design a bit of a software architecture that we wanted to use ’cause we knew it worked. And we talked that through with the team and it meant at the end of the kick-off not only have we done the things we talked about, we talked about the business model, we talked about what success looks like, but we also had the first beginnings of how the software was going to be organised as well. So that was quite nice.
JG: All right, I really like this part of the discussion when you talk about how important it is to understand the division and to engage people because apart from obviously getting to knowledge about the company and the business it really boosts the motivation of the team. And I can feel it when I’m working with the teams here in Future Processing, so the knowledge about how the company works really gives positive energy to the people.
SB: Okay, well that’s good. The other thing I would say to anybody who’s working, is going, is also, in processing things like this is listen to the supplier. So that’s a good example where your supplier is saying ‘if you do this, the team is more motivated’. So you know, they have probably a lot more experience in working outsource projects than you do so listen to them and pay heed to their advice.
JG: Okay Steve so to summarise what can be done to minimise the risk of a project failure if we concentrate on the project kick-off?
SB: So probably number one as I said is have one. Number two, make sure you agree what the outcome is that you’re trying to achieve from this project. And probably the third one is to agree what your initial process is going to look like, particularly if you’re working with an outsource developer. You don’t want to be spending your first couple of iterations arguing about how you’re doing it. Agree on initial starting position because you can always adapt the way of working as the project goes on.
JG: All right Steve thank you for interesting discussion and for the tips that you provided.
SB: You’re very welcome.
JG: And thank you for watching this episode of IT Leadership Insights by Future Processing. If you found that useful and you liked it please share it and recommend it to your friends and colleagues who might need that knowledge and let us know if there is anything you’d like us to talk about in further episodes. Until next time.
Whitepaper: IT outsourcing lifecycle
How can the process of collaboration with an IT service provider look like?Find out more
IT supplier management - best practices
In this episode of IT Leadership Insights, Jarosław Granat speaks to Lauren Tennant about the best practices in managing IT service suppliers.Find out more