10 reasons why your project may fail
Everyone who starts their adventure as a PM or even those who have many years of experience asks themselves the same question: "How to manage a project and achieve success." That is also the question that begins every new cooperation with our clients. But there is a stage of our collaboration when we ask one more, and of great importance.
If you want to find out the question and how we set the project with our customers, follow the white rabbit...
The information you are going to find in this article is not theoretical or based on some short survey. On the contrary, these are examples that we have observed during the work with our clients for the last ten years of doing the IT business (10 years have passed this year, wishes in the comments are appreciated ;-) ). By reading this blog post, you will learn about ten elements that are usually obvious for our clients, but when we change or remove them, we instantly get better results. And in the end, this allows us to release new features faster by 70%.
At Accesto, we do not have our own product, but we help others to create or improve their software products. Detailed information on what we do can be found on our website: Accesto. More on what projects we have implemented and with what effect can be found in the Case Study tab .
Problem-solving thanks to Scrum
Commonly there is a stage of cooperation when we have a certain level of trust with our clients. After that, usually they are ready to hand over the project management to us.
Currently, we start each new project with a workshop with the client. We set the Scope for the next sprints, product roadmap, etc., ending with a decision on how the communication process and management of the entire project on both sides will be handled.
After finishing 60+ projects, we've noticed that in each case, there were 1 or 2 elements that we did not pay attention to at the initial stage. Of course, in the end, it always turned out those elements had an impact on the entire project.
The key part was to organize a sprint retrospective a bit differently from all the others done so far. As a result, all our Scrum teams had to face one valid question
What bad practices have you noticed in other organizations that have a great impact on the project implementation?
The effect was amazing and showed the problems our clients faced from all angles:
- development
- management
- communication
What problems did our teams notice in the projects we helped?
1. Allowing the client to access the tasks board (company owner).
Our developers voted for this element as the most problematic. For our specialists, it was the factor that ruined their working day the most. It is the moment when our customers usually start to multiply tasks without necessity. It breaks the Product Owner's backlog. Tags are often added in an incomprehensible way and all with the highest priority.
From a certain point, to make cooperation with clients more effective, we create a separate board so that he or she can add additional elements to the project. All tasks must be arranged according to priorities, e.g. using MoSCow methodology.
2. Testing done by a person who does not know the business side of the project or does not do quality assurance at all.
Let me give you a brief description of what I have in mind… We conduct a review, there is an inspection, we change some things, adaptation takes place, and the whole thing goes to testing. The client gives his testers the tasks but does not provide them with new business findings. In the end, there is a lot of time wasted, because they report bugs, which we then analyze, only to find out that the problem comes from a project change. From that moment on, whenever we hand over features to the client, we make sure that the tester knows the entire scope of the project.
3. Theoretically prepared sprint... without planning it with your team
Scrum, agile, are two therms very fashionable now, appearing in many industries, especially in IT. It is hard to find a company in a new technology business that is not using Scrum and is not Agile. But is there truth out there?
No, the fact is that many companies do not know exactly what this whole Scrum is, who the Scrum Master is, and that Scrum is easy to understand but hard to master. You don't have to introduce full Scrum into your organization right away. It is a good practice to run the framework and check how the team reacts. Too strong and large changes can be perceived negatively. By acting this way, we produce various “creations” in which no one knows what's going on. Planning is just about getting tasks out of the backlog by the Product Owner and declaring: let’s do it. Remember that each sprint is a project in which we have a goal to achieve, and we must define it when planning.
4. Frequent and large in a scale team rotation
There is no need to explain much here. Each change reduces speed and quality. It brings chaos and adversely affects the team's motivation. Additionally, every rotation causes a loss of some knowledge about the project, and unfortunately, it is not possible to document everything.
5. Running a project without a clear development direction
It is of great importance for the team, whether the project will see the light of day. Otherwise, there is a feeling that the work was for nothing.
Another aspect of this is that if the team knows in which direction the project is going, what we want to achieve, it gets more involved in it and chooses solutions in a better way.
6. Ill-considered features
Usually 60% of the application features are unused or used very rarely. It brings a similar effect to teamwork as in point 5, but we want to draw more attention to this case.
As a result, applications are overloaded, UX is falling, the team is nervous because their work was compromised once again. You have to put a lot of effort into educating your clients, that not everything that the end-users are suggesting or complaining about regards the application must be implemented immediately. You should carefully analyze in which direction to develop the application.
7. No team leader/product owner
There must always be someone on board setting the direction. Without the right person, the project - very often - is going in the wrong direction, disinformation occurs, and nobody knows who to ask for information.
8. Code review done by people unfamiliar with the application
The process looks as if we checked the individual parts of the car, but did not establish what car we want to produce. The developer solution may be good, but it doesn't fit the project at all. Later it may cause unfavorable effects, e.g. a given functionality should be easy to edit and with the possibility of implementing it in several places... but is not. Or the developer did not take into account some important dependence between functionalities, which of course is causing problems in the future.
9. Long-running QA/CR
We have a sprint and its goal that we must achieve. Delaying testing or code review may result in not being able to implement the corrections before the sprint's end, and thus its goal will not be achieved. Another problem occurs when the developer begins to implement the next tasks when CR/QA is still pending. The knowledge about the task is lost, and the developer has to come back and read it again. Often the tasks without CR/QA are blockers for other elements, which delay their implementation.
10. Create a large project with a lot of integration without writing tests
Remember that a lot of integration means a lot of connections between particular features. If we do not introduce the tests, it could cause new changes to bring errors in other elements. Without properly written tests, we cannot control it.
Summarizing what not to do in projects
Seemingly simple and obvious elements can have a significant impact on a project. Let's not focus only on positive elements that improve work, but remember about eliminating those that may have a negative impact, including the comfort of the teamwork. Each project is different, and the fact that something works in one does not mean that it will work in another, which is why it is so important to talk, communicate and set some rules on how to work at the beginning of each project.
If you think of some other elements that we could add to the list, I will be happy to talk to you about it.
