Communication is the key. Do this right and your project will succeed. I will expose 3 big risks in software projects and tell you how to avoid them. Follow these suggestions and your chances will massively improve.
1. Unclear Expectations​
Unclear expectations are dangerous. They can be very expensive at the least or disastrous at worst. Yet, they are not uncommon. Teams spend hundreds of hours of effort to create a value that no one asked for. Unclear expectations can lead to lost money or jobs.
Unclear expectations are normal, though. They will happen more often than not. And if they do, don’t see them as mistakes, offense or incompetence of yours or others. Everyone is unique, grew up in a different environment and was exposed to different experiences. All of us think differently and see different things as “obvious” or “self explanatory”.
Miscommunication will happen. And that is a good thing. Let it happen. It will expose imperfections in your communication process and will give you a chance to improve it. But it is very important to not ignore miscommunication. Unclear expectations are usually easy to fix but require efforts on both sides: the stakeholder and the provider.
To avoid the risk of unclear expectations it is enough to come up with a proper SOP (Standard Operating Procedure) in the form of a checklist.
An example of the first checklist looks like this:
What outcome do I expect?
Will I be happy with anything less?
Why do I expect this particular outcome?
What constraints there are?
Ask what is possible.
Follow this simple list and you will save yourself many headaches. Detailed explanation with examples comes in next paragraphs.
What outcome do I expect?​
Write it down in a short, but very concrete sentence. It should take the form of a thing that already happened, not as an action to do. e.g. “bank transfer is enabled as a paying method for users in the eurozone” not “enable bank transfer for eurozone”. This is sometimes called an Acceptance Criteria. And if written properly, leaves no space for interpretation and allows you to test the outcomes (sometimes even automatically).
Keep in mind that it is natural for your expectations to change. We will talk about this in depth in the next couple of minutes.
Will I be happy with anything less?​
Prepare a simplified expectation. Usually you can solve 80% of the problem with 20% effort. Think about what could be stripped down from your expected outcome. Do you really need this in real-time or is it 4h late enough? Do you really need to sort and filter on every column or maybe just the date? This will prepare you to save the day (and time) once things get hairy during development.
Why do I expect this particular outcome?​
Write down a sentence or two explaining why this outcome is wanted. This helps you to formalize and validate your expectations. Maybe you will learn something new or change perspective. On top of that, by setting your expectations in a context, you will help others see and understand the problem the way you see it. This reduces the chances of misunderstanding and even gives an opportunity to find alternative solutions to the problem. A good example would be “Our customers demand a bank transfer as a payment method but our current payment provider allows this only for EUR currency”. A bad example is “we need bank transfers as a payment method”.
What constraints there are?​
Give yourself a minute or two and think about any limitations that apply to your expectations. Maybe you have an important customer onboarding scheduled and the feature must be implemented before this? Communicate this clearly! Every person responsible for delivery must know what constraints there are. Be it financial, technical or simply time constraints.
Ask what is possible​
Everyone's an expert in her domain. Everywhere else we make assumptions. Do not endanger your success. Ask experts if the expected outcome is possible given the constraints. And if not, ask for the simpler alternative you already prepared.
2. Changing Requirements​
Requirements change. This is a simple fact. When you mature, your expectations change. Same goes for your features, products and business. Do not fall for the “never change a running system” meme. Why is this a risk, though? Read on to figure out.
When requirements change, the risk of Unclear Expectations arises. If requested changes were communicated verbally or somewhere on Slack and were accompanied by a vivid discussion, it won’t be clear for the developers what to deliver. Even worse if there are multiple channels of communication in your organization: E-mails, multiple Slack channels, Jira tickets, Wiki documents.
It is imperative that you settle for a Single Source Of Truth and document everything in one place. Be it a ticket in your system or a Slack channel created explicitly for this issue. Keep all discussions formal and documented. This helps to track why decisions are made and what is the final verdict.
Document when things changed and why they changed. Date of change is very important. You can compare it with when was the last time software was released to see if your change is available. It is important information to reason about the problem with all stakeholders and developers. Equally important is the “why”. Not for blaming but to learn and improve the system. Like a black box on an airplane shows what went wrong before the crash, similarly a formal record of changes shows what could be improved if things go south.
As you see, communication is a challenge within a single team. But things change drastically if you depend on others. We will talk about this next.
3. Dependency On Others​
You can test, understand and rely on everything you control. Everything else is a risk. The more dependencies in your software project, the bigger the risk that someone will bring troubles. Planning and communicating in a single, standalone team is very difficult. Every extra team in the equation multiplies the efforts.
Dependencies take various forms. It could be a decision from one of the stakeholders or managers, internal service provided by other teams (think authentication or some kind of platform) or even a library your developers use. If something is not maintained by you or your team, it's a dependency and it can go wrong.
There is no silver bullet for dependencies. Organizations are complex systems and we all are meant to operate together. And this is good! Dependencies allow us to throw away some of the responsibilities and focus on producing real value. But you must prepare for the failures of others.
Make a list of all your dependencies and answer following questions:
Do we really need this?
What is an alternative and what it costs?
What will happen if it disappears?
What will happen if it changes unexpectedly?
What will happen if we need it to change?
Who is my contact person for this particular dependency?
Conclusion​
In this article we listed 3 big risks in software development and briefly explained how to avoid them. Software is hard and expensive. Oftentimes it is worth asking for a second opinion to avoid costly mistakes. I would like to ask you to share this article with anyone who deals with software (maybe on LinkedIn) and I invite you to contact me using the button below and tell me about your business problems. It is free and I’m sure you will get massive value out of it.