In software project management, communications is key to ensuring that your project will be successful. It keeps you up to date with how the project is proceeding, shows the developer that you care about the project, and that you are willing to get involved to ensure its success. Providing rapid feedback to your developer is important to keep the project on the tracks. It also provides a means for holding the developer accountable.
Communications can be done through numerous methods such as phone, Skype, email, project planning, issue tracking tools, etc. The key is that you get regular updates, and that you have a central place to keep track of features and defects. I require daily status reports from the developer even if it is only a sentence in an email. For most projects, a daily scrum meeting at the beginning of the work day will get everyone started on the right track every day. If a developer is not going to work on a given day that they are normally scheduled to work, I expect a quick note that they will be unavailable.
Needless to say, if you have a lot of bugs in the software, your customers won’t be happy. Since developers are notoriously poor at testing their own code, it is up to you to ensure that the program gets tested. This might mean you wind up doing the testing or might mean you have to hire a QA (Quality Assurance) tester/team.
The key to dealing with defects is to find them and get them fixed early. The longer it takes to find a bug and the further it gets into the development life cycle, the more costly the defect.
The chart below shows the relative cost to fix a bug at different points in the lifecycle. Note that it is not linear and the cost increases significantly the further the defect gets in the development process. Think of all the people that get involved later in the cycle.
It is important to give deep thought as to what you want to accomplish with the software. If you tell a builder that you want a building and give no other amplifying information, what do you think you would get? Would you get a house, a garage, an office building, or something else? About all you can be sure you will get is a floor, roof, walls, and doors. Now suppose you tell them you want a house. With this increased specificity, in the US, you are likely to get a building with a kitchen, bathroom(s), living room, and bedroom(s).
This is still far from enough information to be sure you and the builder are thinking along the same lines. You could be thinking the White House and they could be thinking a starter house. The more detail you give the builder, the more likely you are to get what you want. This same concept applies to developing a software product.
How does one define success and/or failure when discussing software development projects? Well, it depends on who you’re talking to. The end user’s definition of success will most likely be quite different than the business who is paying to develop the product. Let’s look at an example of what a business’s definition of success might be
The project meets the needs of the business unit at the desired price and the specified time frame.
Very few projects succeed on all of those fronts – functionality, time, and money. You could in fact fail by that definition, but still have many happy users. The point here is that even with happy users, you may not get more work from the business because the person paying your bill might not like the cost overruns. I’d venture to guess that most software development companies would view this scenario as a project failure.
Are you interested in having your own software product created but don’t know where to start? Or maybe you have tried it in the past and have run into many issues. If you would like a guide to help you navigate the potential pitfalls of software development, then download the “Developing a Software Product”.
The download is free and there is no obligation. We don’t even ask for an email address unless you want us to send you updates to this continually growing guide.
Depending on who you listen to, the majority of software projects are failures. In order to determine if a software development project is successful, you must first understand the meaning of success. In this article we’re going to define how we determine whether a project is a success, discuss some known factors that lead to project failure, and ultimately show you how your software development group can help your organization be more in tune with actual business needs (thus, resulting in more successful projects).
Traditionally, we know we can define success in terms of product delivery. If money is spent and no application is delivered, then the project was obviously NOT a success. Software development isn’t quite so cut and dry though. There are other pieces to the software project puzzle that must fit together in order for it to be considered a success. It’s not just about whether or not the project team delivered the product. We have to also take into consideration factors like: