The Nature of Software Development Projects

The first issue concerning software development projects is the fact that many of them are unique. So unless you’re developing the exact same software over and over again, the parameters differ too much to use them as a one stable point of reference.

The second issue concerns the rapid evolution of technology. We don’t even have to go back 50 years for comparison — it’s enough to see how much has changed just in the last decade. Software development has no choice but to reflect that in the form of constant new programming languages, frameworks, libraries, and tools.

On top of that, clients’ needs along with market demands change as well. Suddenly, the websites have to be SEO friendly, their mobile versions need to be top–notch to satisfy the constantly raising market share of mobile devices, and web apps need to be restricted to one single page, following the example of Facebook and many other successful projects.

Also, it will be beneficial to follow mobile SEO strategies to enhance user experience and improve mobile conversion.

It’s a lot. Each project has the potential to bring something new, and the proposed solutions can’t always be based on experience gained by the years of delivering different software. That’s what makes software development’s estimations so difficult — there’s simply too much uncertainty and novelty to be able to properly assess each project.

That’s also the reason why being an optimist doesn’t pay off. Assuming that everything will go well with no delays, that there won’t be any bugs to fix or last–minute changes, is naive. By thinking of the worst–case scenarios, you can predict many issues and prepare for them in advance — for example, by adding time buffers in recognition of sick leaves developers might have to take.

To properly and masterfully manage all those unknown variables, Steve McConnel, an expert in software engineering and project management, introduced a concept known as the Cone of Uncertainty. It’s a model describing the level of uncertainty throughout the whole project — at the start, the level of uncertainty is huge. The more time passes though, the more data you gather and therefore, the more you know. And so the challenge lies in achieving that level of knowledge as fast as possible.

Software Development Project Plan

Software development plan describes what needs to be done and how in a clear, concise manner, so that the whole team knows their roles and responsibilities, but with enough flexibility to reflect the tumultuous nature of software development.

Instead of having one strict deadline for the whole project, it’s divided into smaller parts instead, and the success rate is measured by milestones. Depending on the type of Software Development Life Cycle, the whole process will include iterations, revisions, and feedback. So even though it may seem chaotic at first, the whole team, as well as stakeholders, will know the state of the project at all times.

How does the software development lifecycle differ from the software development plan? The former is a specific roadmap, describing all the steps and their order necessary to complete the project, while the latter focuses on explaining the scope of the project and all its circumstances. In short, a software development plan explains what will be done and why, while a software development lifecycle explains how it will be done.

Now that we got all that out of the way, let’s move on to the phases that will ensure a proper software development plan everyone can rely on.

Defining The Problem

The first phase starts the moment the client contacts a software house. During the first talks, besides deciding on terms of cooperation, the client should say:

• What software project do they want exactly,
• What problem it should solve,
• What demand it’s answering,
• What business objectives or specific goals hide behind that decision,
• What will be the criteria of project success.

The software house’s responsibility is to discern whether the project matches the business decisions.

Think of it that way — the client doesn’t come with a project idea, they come with a problem. The vendor doesn’t deliver a project: it delivers a solution. If the solution doesn’t solve the client’s problem, it’s a waste of money. Period.

Finding The Solution

This phase focuses on discovering what can be done to fix the problem and how. And also, whether it’s possible to do so in the first place with the client’s budget, time limit, and other restrictions. That’s within the vendor’s responsibility to figure out, with the client’s help.

Here’s a time for settling on the project’s scope. Besides focusing on the how, it also has to be decided with what — when it comes to tools, languages, resources — and who — when it comes to the members of the software development team, any external groups whose help is needed, and who will be the project manager.

When all of the above has been decided, it’s easier to give a rough estimate of the budget and first deadlines.

Perfecting The Idea

Before digging into details, it’s important to decide on the essential features of the software project (usually via workshops). All the nonessential features should be categorized as “nice–to–haves” to ensure the right order of priorities. If your software project looks modern and sleek, but doesn’t serve its intended purpose, it’s a failure.

Only then you can start creating all the wireframes, user stories, and prototypes. Due to that, you can check if everyone’s on the same page, deal with any misunderstandings or dispel any doubts, as well as assess the risk. This part is also crucial to collect all the feedback you possibly can — mainly from the stakeholders and project team members.

At this point, a final estimation is possible: the scope of the project, the timeline, budget, and so on. There are still uncertain variables in play though: while the scope of the cone of uncertainty is smaller at this stage, it’s still significant enough.

Preparing The Environment

Once the whole scope of the project is known and understood by all, it has to be broken down into smaller phases that end with milestones. A good example of this is sprint, frequently used in agile development, which is a small time–boxed period with set tasks to complete. Sprint is repeated as many times as it’s necessary, till the project’s completion.

This approach ensures constant revision of what’s been done and what’s still left to do, making it easier to control and manage. Those frequent progress checks are also more convenient for stakeholders, who are kept in the loop throughout the whole project.

The biggest upside of creating such a project schedule is its flexibility. It’s easier to implement any change requests, catch glaring mistakes quickly, and to improve the software development process itself at any moment. Most importantly, it makes it simpler to check whether the product delivers significant value to the end–users.

Execution

Once everything on the project organization side is complete, it’s time for the developers to bring the idea to life. It’s also a good moment to set quality assurance in place, if it hasn’t been yet, to simultaneously fix bugs and any other reported issues. Additionally, you can also include User Acceptance Testing (if that’s applicable to your circumstances) or even involve your client in the final testing stages.

Delivering The Answer

At this point, software projects should be done with optional last–minute tasks and bug fixes left to do. But this stage should mostly focus on the release of the product and all the supporting processes surrounding it. Those can be: connecting the domain, activating the website’s certificates, adding payment features, and so on.

See also: How to Buy a Domain Name

All the results should be observed and analyzed, gathering feedback from users and responding to it. Especially if the product is in its beta version, it’s important to check how the users interact with the software, whether it serves its purpose, and if it’s up to everyone’s expectations.

The last thing left to do is the handover. The whole project needs clear and completed documentation, explaining the whole work done and the current state of the product. It ensures that in case of any future development needed, whether it’s further improvement or simple changes, the new development team will be able to jump right to work, without having to waste time to figure out the code. That’s why it’s also necessary for the code to be fairly clean and straightforward.

Common Mistakes In Software Development Planning

Since we know now how to construct a good software development project plan, it’s also proper to know what to avoid. The pitfalls tend to happen on both sides, on the client’s side as well as the vendor’s. Here’s a brief description of what can negatively influence the whole collaboration:

Client’s Perspective

• Lack of understanding and knowledge of software development process that leads to unrealistic expectations,
• Demanding drastic changes halfway through the project that go against initial principles,
• Not being clear enough on the requirements, needs, and goals,
• Too many people in decisive roles wanting different things and trying to answer the question of how to resolve the problem instead of sharing common goals.

Software Development Company’s Perspective

• Overpromising while overestimating capabilities and experience while not taking into account uncertainties,
• Bad communication with developers on the sales’ department side,
• Bad internal communication between team members,
• Putting up a wall between the client and the development team (often in the form of unnecessary middlemen),
• Not including any buffer in the schedule for fixes, unexpected issues, holidays, and sick leave,
• Neglecting to carry out tests with end–users before the release.

Key Takeaways

A good software development plan should include answers to the following questions:

1. What problem does your client want to solve?
2. What business results does the client expect?
3. What can be done to resolve the client’s problem?
4. Is it possible to resolve the problem within the client’s means?
5. How can it be resolved?
6. What resources are needed to resolve the problem?
7. How will the development process look like?
8. How will the project’s progress be measured?
9. Was risk assessment conducted?