Setting your expectations straight
I'd group software lifecycles into 2 groups:
- Immediately killed
- Lives for many-many years, even decades
The first is important because it happens due to various forms of bad communication. The second is important to set ROI expectations right. In this article, we'll talk about the first. The goal is to cover why a software project can die from its inception, all the way up to when users are using it.
Let's grab a shovel. We'll dig deep!
Dead projects! Dead projects everywhere!
Projects that are immediately killed have their red flags from the beginning. These are the kind of projects where people shake their heads and say: "It was obvious from the beginning that this is not going to work". These red flags can happen at different parts of the project's manifestation to life. A software project generally has the following 4 steps from ideation to delivered product:
- The customer has a problem and they contact a developer
- The developer creates a specification
- The developer implements and deploys the specified software
- The developer teaches the customer how to use the program
At each of these steps, things can go bad, and almost all are communication-related.
1. The customer has a problem and they contact a developer
Sometimes, the customer approaches the vendor as if it were a waiter. They think they know the solution to their problems and the vendor is there to act as the hands that solve the problem. They are 100% sure that this will solve their headache. It's nice when the developers share their opinion, but "they don't know the business, they should just stick to coding". This relationship is typical if the developer lacks industry experience, or if the customer is ... "bossy".
Other times, the vendor acts like a doctor and the client plays the patient part. He feels pain, he wants a remedy. The developer might know a fix. It can be small, it can be a multi-year project. But he suggests something and the client believes him. In these instances, the vendor is treated as an expert.
The possible problem that can happen with these 2 scenarios is that the client can be mistaken, or the expert.
How can we avoid these risks?
Try to pick well-positioned experts who know your field. This will nudge the first type of clients to listen more to the developers and reduce the risk of choosing a bad solution.
2. The developer creates a specification
Step 1 is done. The client wants something. They shake hands and the work starts. Unless it's a micro project, a plan has to be created. A specification that describes how the final software should look and behave. The better the details, the more precise the estimates will be, and the more unknowns are dug up. This is done by communication between vendor and client. The vendor's job is to excavate information from the client's employees.
Problems that can happen at this phase:
- Some people will only tell things that come to their mind at that certain moment.
- Some people are better at telling things than others.
- The interconnected processes are not explained well, because the involved employees are not there at the same time
- How the developer understands things will be different ( lost in translation)
- Client doesn't review the specification properly
How can we avoid these risks?
- Structured interviews: event storming, group sessions, process documentation, workflows, UML diagrams, etc
- Dedicating time for interviews, and not rushing the analysis process
- Proper reviewing of specification
3. The developer implements and deploys the specified software
During development, much more communication is needed. Even if the project is just a small gig, there will be questions. Questions regarding:
- Usability
- Environment
- Security
- Business goals
To answer this, there has to be a single point of contact on the client's side, a "champion". The champion has to be dedicated to this project, meaning that collaboration, testing, and goal setting should be part of his job, not just an afterthought. If there is no champion, the whole project is in jeopardy.
We had a project previously where we installed Odoo for a client. It was fine initially, but the champion we had from the other side was not enthusiastic about the project. His approach was to always "have the ball" on our side, meaning he always gave us some minuscule task or question, so that he can do what he wanted to do. This of course doesn't move the project forward, quite the contrary. It forced the project to a standstill, which was fine from the champion's perspective, but bad from the owner's perspective. The project initially failed because the image the CEO saw was that nothing is moving, multiple problems were presented as much worse as they were in reality.
Another common problem is that stakeholders pull out at this phase. They have important things to do and one or more trusted employee takes over. This is not a problem necessary but if the project is not specified properly, the decisions the employees make can be suboptimal. The main issue is that employees focus on the what: features. In contrast, stakeholders' eye is on the why: the value the project brings.
These bad decisions can cause:
- Unnecessary features & scope creep
- Budget overflows
- Missing the big goal
The developer's job is to question or push back decisions by asking: "Does it bring value? How is this related to the goal?". It is always useful to have a monthly review with the stakeholders. Questionable decisions can be reviewed, and the budget of the project can be kept at bay. I have seen multiple CxOs have their eyes go wide when they heard that the initial budget has already run out due to scope creep, and the project is only half ready.
Problems that can happen at this phase:
- No champion on the client's side.
- The champion is not dedicated, just works on the project when he has time or feels like it.
- The champion sees the project as a burden, therefore not helping in its progression.
- Stakeholders completely pull out, resulting in scope creep, budget overflows, and a slow drift from the target goal.
How can we avoid these risks?
- The client has to have an internal champion. Allocate time for this employee, not just assign the project as a nice-to-have side task
- The vendor should push back if the project starts to move away from the original goal
- Stakeholders should be kept in the loop
4. The developer teaches the customer how to use the program
This part can kill a project in multiple ways. If the project is a non-essential part of the business, the users can fall back to their old ways. They don't feel that their needs receive the proper care, or don't know how to use the software to make their lives easier. I've seen this happen. Management checks back on the project after 2 months only to realize that nobody is using it. Another issue can be that even though they want to use the system, the experience of the application or the learning is so discouraging, that they revolt using it. If they have political power, the project can be canned.
The teaching part can be done in conjunction with the previous phase, or directly after. The more complex the system, the more education it requires. For smaller projects, resourceful users can "wing it" and learn by themselves. My experience is that having a big initial teaching session will only give a general overview of the system to the users. The real learning starts when they begin using the system.
After the software goes live, the initial 1 or 2 weeks need more care from the vendor. Scheduling a daily meeting is beneficial for all parties. Users can learn from each other, the vendor can learn about common issues and provide solutions faster. After the first few weeks, I like to switch to an open office type of approach. This means that users are not mandated to participate, but if they want, they can. 1 or 2 timeslots per week is fine. This will measure the need for the requirements for the meetings. If participation dwindles and the questions become nice-to-have discussions, these meetings can be stopped.
Regarding written documentation, I don't find them useful at all. Written documentation is a thing that every vendor hates to create, every client demands, and no one ever reads. It's much harder to keep it up to date and the whole wording is very dry. I very much prefer video guides. Faster, less dry, gets to the point faster. The only issue is the maintenance. If one thing changes, the vendor has to create a new video. With a written document, you just update that part.
Problems that can happen at this phase:
- After the initial release, the availability of the vendor is sparse, not aligned with the increased burst of questions and problems.
- No follow-up education, when users start to use the system.
- Missing or improper documentation.
How can we avoid these risks?
- After the initial release, have daily meetings with Q&A between vendor and client. Do this for 1 or 2 weeks.
- Have a weekly Q&A after this period for 4 to 6 weeks. Consider having it in an open office style.
- Discuss the documentation format and coverage before the project.
5. The software is in use and maintained
If the previous steps were done properly, there should be no issues here. The danger of fixing things at this late stage is that it costs much more to do so. Look at the following chart:
The chart mentions defects. You can consider these bugs or improper features. The earlier you catch these, the better. At this stage, if a problem is found in a feature, it costs magnitudes more to fix it, than in earlier stages. If you follow the steps I mentioned earlier, you have a higher chance that you have a software that users are happy to use, and increases your profit.
If the specifications were off, there was little communication during implementation, the focus on the WHY was lost, then the end users won't use the project.
Change management with the champion and proper support from the vendor.
This is the part where some people realize that software is never truly finished.
Why is it killed at its crib? Because users don't use it.
- Bad requirements
- End users don't use it:
- Bad experience (UX, performance, bad specs)
- No "champion" present: no proper emotional support, lack of training
- No change management: they don't want to use it
Leadership can hold the smoking gun too
On a few occasions, leadership kills these projects. It turns out, the fate of ERP systems often falls victim to the duo of politics and budgeting. The world is changing and what seemed like a doable challenge at the beginning became an impossible task. Even though every step from the previous chapter is done flawlessly.
Don't get me wrong. Specifying, implementing, and deploying a big software is very hard. So hard that it's impossible to ship software without misunderstandings, bugs, and technical issues while doing it. Above a certain size and complexity, there's too much communication and too many things can go bad. The goal is to expect this. If you clean up an old house, you have to get your hands dirty. If you create new software, things will get messy. But that's the journey. If the result solves the problem, you WILL save money.