Tips to Successful Software Projects Part 1 1

How a software project starts can determine the level of success of the project. The schedule is probably tight and you don’t find much time to prepare. However, jumping straight into the project and neglecting preparation will most likely come back to haunt you later. So, it is important to kick off the project with adequate preparations.

To increase the chance of the project’s success try out the following tips.

Establish Clear Communication Paths

From day one, make sure the roles are well-defined and everyone knows who handles what. Make sure the key contact people are easily identifiable and make sure that information is accessible to everyone.

In addition, in a large organization, a project will likely involve other teams. Identify those teams and start the conversation with them early. The last thing you want is to have a chain of dependencies that causes your project’s progress to suffer.

Define Conventions and Best Practices

When the project kicks off, don’t immediately jump into coding. If you do that the codebase will end up as a tangled mess (“spaghetti code”) that is not maintainable.

Instead, take some time to discuss with the team on the conventions and best practices to follow. The end result will be a list of conventions and best practices that the entire team came up together. By following the established best practices and conventions it will bring organization and make sure everyone is on the same page.

Define the Definition of Done

It is important to define what is the definition of done. For example, a developer would consider a feature is done if they build the project and it works in their local machine. However, that same build might fail in another environment. In such a case, the feature is not necessarily done because it is not functional outside of the developer’s local environment.

Regardless of how many environments the project will be running in, it is important to make sure they are included in the definition of done. The end result should be a definition of done as a checklist that can be checked off to determine if a task is complete.

Decide on the Tools and Applications

Each developer has their own preferences on the tool to use for development. Some like the command line and others like to use GUI alternatives. One developer might prefer Eclipse, while another like to use Visual Studio. Developers love to have the freedom to choose their own tools, but that is not always the optimal way as a team.

So, some core tools and applications must be determined. For example, which IDE (integrated development environment) to use and which application to test API (application programming interface). From just those two things we can see the advantage of having them be the same for each developer in the team.

Consider the case when a developer (John) needs help with API and went to ask his co-worker (George) for help. George uses Postman for API development and testing and John uses SoapUI. As you can imagine, that is a problem and how often a phrase like “I am not sure how to do that for SoapUI.” will be said by George.

Similarly, John might be using Eclipse for Android development and George is using Android Studio. Reaching the same outcome will involve different steps and obstacles, which result in George not being able to help John much and vice-versa.

Identify Work Flow with Version Control

Version control is a must have for every software project. It is impossible to develop a software project collaboratively without using one. However, deciding on a version control system to use is not enough.

You must also define how the workflow is for using the version control system. Do you have one branch (master) and all changes get push to it? Do each story get their own branch and only get merged into master once it is ready and reviewed by other developers? Do commit messages need to be in a certain format? These are some things that need to be made clear at the start, so everyone can be in sync.

Identify the Must Have and Nice to Have

Have you ever experienced scope creep for a software project? The timeline is tight and the MVP (minimal viable product) was vague but you know it must do A, B, and C. Then mid-way in development, somehow the MVP is A, B, C, D, E, F, and G. To help with this kind of problem, you can create a must have and nice to have list at the start of the project.

The list will clearly identify what are the requirements for MVP and what is not. So, why do you want to document it when everyone on the team understood the MVP is A, B, and C? Well, that’s because everyone’s interpretation of A, B, and C might be different. For example, one person sees displaying a confirmation of an order by showing some text. While another sees it as showing a pop-up card with all the information nicely broken down and are editable as well.

Putting that into a real life example, let say the stakeholders see the confirmation (feature A) as a pop-up card and your team sees it as showing some text. There is no documented list of must-have and nice to have, so mid-way in development the team finds out what they have in mind is not what the stakeholders have in mind. At that point, the confirmation feature suddenly explodes into several features. Now feature A turned into feature A, B, and C.

So, by documenting the must have and nice to have you eliminate the confusion early — even before development. It helps keep your team aligns with what the stakeholders want. This ultimately brings benefit to the development team and stakeholders.

I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.

What are your experiences with successful or unsuccessful software projects?

To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.