Within dozens of projects, I had the pleasure to work on, only a very small amount of them could be claimed successful. Did you have the same feeling, that during the development phase of the projects, you could instinctively know which one of them would be a success and which will become a failure? What is the difference between winning and losing? Can we prevent it?
I have a very strong feeling that this is kind of cliche, everyone knows what good projects should look like, so why are we still failing?
I’ve put some thought into this topic and here I’d like to present 4 significant factors, that differ hooray! from dammit!
Wishful thinking
This is something I’ve explicitly put in the first place as the main factor of failing projects from my perspective, what does it mean then? There is an idea of a project, usually quite ambitious, but from my observation, the more ambitious the project, the less time is to finish it, not to mention the resources which tend to be scarce, does it look familiar? I will be completely honest with you, super ambitious projects with scarce resources tend to be successful, although the fact that no one takes into the equation is that chances are meager. All that expectations combined, lead only to frustration and anger. To avoid that, plan it, and include all the parties' Business, Development, QA, DevOps, etc. at the very beginning of the project, not during the implementation phase. The results might surprise you.
One side communication
Every company is saying, we are a team, we are together, etc. But what is the rate of companies that actually mean it and not just repeat that cliche stuff we have heard thousands of times? Often I faced a situation when a business had been communicating the expectations, and setting timeliness then that was it, no feedback expected, no cooperation before, and no review. When teams get only two choices, adapt or fail, unfortunately, the second option would be more likely. The more effort we will put in during the phase of creating the requirements the better output we will receive. Review and feedback are sufficient to deliver good-quality tasks into the work pipeline. This pyramid known for ages already indicates that it costs 10 times more to fix problems and issues once they hit production. Just have that in mind every time you decide to cut corners and skip communication to speed up things.
QA
Factors described above lead to a point, where we start testing. Just to summarize, the project was created based on the wishful thinking of achieving something great and ambitious, everything was presented to the team as something carved in stone with the expectation of just doing it, then we estimated the stories, we develop them, and at the end, everyone is surprised that the sprint goal has not been achieved, when you go into the details you realize that 80% of tasks have been rejected, because requirements were poorly described and everyone was rushing to meet the deadlines. The problem only increases exponentially as the project becomes more complex and advanced.
Estimation
I still remember this joke that PM is a person that thinks 9 women can deliver a baby in 1 month. Jokes aside, this is unfortunately still true in many cases, the points above stacked together: wishful thinking, one side communication, and not taking QA into account, all of this together lead to the creation of roadmaps and estimations which are impossible to achieve from the very beginning.
Summary
This article pointed out some things from a very one-sided perspective, as all of these things I’ve been observing from a QA point of view. If I could shortly give a recipe for a successful project just in a few words that would be:
- Engage everyone early
- Provoke discussion
- Be open to receiving and giving feedback
- Balance the expectations and reality
- Don’t only be a team, behave like one
Top comments (0)