Prevention is better than cure. There are no doubts about it. But to be able to prevent the trouble, one must know what signs to look for. Especially when everything looks to be functioning and nothing seems to ring the bell.
After more than 10 years in software development and IT consulting, we know where potential problems are hidden and what are the first signs of an upcoming crisis. In this blog post, we want to share some of these alarming hints with you.
What is a successful IT project?
Before we start let me explain what we consider to be a successful IT project. This way it will be easier to rationalize the below-described threats and their first signs.
A successful IT project is the one that wins in the market. And to do so it has to:
- deliver features quick and reliably;
- allow the business to react promptly on changing demands;
- continually gather and implement feedback to satisfy current and attract new customers.
Moreover, IT project success is not a static value. In the world of fast-developing technologies, what is good enough today, is not so in a year or even less. That’s why we always put the practice of continuous improvement into the concept of a successful IT project.
The hazards that we address in this blog post militate against the IT project success as we understand it, and can emerge in various components of a project: technical, management and cultural. With all these entering points being clarified, let’s jump directly to the main topic:
Accumulating unplanned work and rework
Percentage of unplanned work and rework that your IT team is doing is a useful metric that shows how quality the project’s code is.
Spotting it and deciding to fix it early on allows you to do deal with it steadily, in a planned manner. Ignoring it – means having to drop everything and run with all hands on board to put out a sudden fire one day.
The choice is yours.
How to handle unplanned work is a topic for another article (let us know if you want us to cover it). Meanwhile, you can read about some tips and IT strategies on handling the unplanned work here.
Testing is performed manually only
I know many will say that having testers on board is already a great achievement. But even having a dedicated QA team is not as efficient as having automated tests created and maintained by developers.
This has a crucial effect on a project, as code gets more testable and developers don’t feel their work is done when they transfer the code to the testing team. Instead, they care more about the longevity of their code and put more effort into creating, maintaining and fixing automated tests. As a result, communication between developers and testers also improves, they work more cohesively and bring features to production much quicker.
And whereas ignoring this sign won’t necessarily lead to a dramatic project’s failure (even though it can), it will for sure leave you behind the competitors who got this practice implemented.
Long breaks between deployments to production
One of the main principles of continuous delivery* is to work in short cycles that allow seeing changes in production fast, and thus react promptly if something is wrong. This way you decrease the price of possible failures and get immediate feedback, that allows shifting the vector of product development according to (changing) market needs. The idea of sprints, both in tech and in sports, is that they’re short but intense.
If your release cycle is long (I would say that having it longer than 2 weeks is a warning sign) that’s a good reason to dig up for the reasons and make it shorter.
*The concept was codified and explained in the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, by Jez Humble and Dave Farley, which we believe is one of the “must-haves” for IT specialists.
Dependency on other app or system
Relying on an external system or application is a common practice, but it creates a heavy burden for your software development team:
- get authorisations from an external party to bring large-scale changes to the project;
- communicate with people outside of the team to perform their tasks;
- using an integrated test environment every time they need to test on demand;
- etc.
We’ve witnessed great business advantages of moving from being dependent on the external IoT system to building in-house on the example of one of our clients – Safe4.
You increase productivity by adding people to the team
We cannot stop emphasizing on how this is a wrong way of scaling the team. Similar to 9 pregnant women being unable to deliver a baby within one month, your constantly growing team wouldn’t finish your project quicker.
What happens in practice is that with more people on board overall team productivity indeed increases a bit, but the efficiency of an individual team member (especially your ‘superstar’ developers) will fall due to more complicated communication, a necessity to supervise others and so on.
Project’s architecture decisions are based on tools and technologies
We often hear from our clients questions like “Shall we implement Microservices?”, “Should we use React or Vue?”, “Which server/tech stack/framework is better to use?’ and stuff like that. If you think the same way and base your architecture decisions on tech and tools only – you’re in trouble, my friend.
Even the most hyped tech stack is useless if it doesn’t help achieve what you want or your team hates using it. It might be tempting to try new trendy tech and tools, but your goals and your team should be in focus while making architectural decisions.
Toxic culture
Somehow the human aspect is often overlooked in the tech world. But performance depends, first of all, on people. And to help them work together effectively, there should be a certain culture.
Google’s massive 2-years study on team performance emphasizes five key dynamics that accompany successful teams:
- Psychological safety: Can we take responsibility without feeling insecure, embarrassed or blamed (in case of a failure)?
- Dependability: Can we rely on each other and expect diligently performed tasks on time?
- Structure & clarity: Are goals, roles, and execution plans on our team clear?
- Meaning of work: Are we working on something personally important for each of us?
- Impact of work: Do we truly believe that the work we’re doing matters?
If the team members are at a loss to answer affirmatively to at least one of these questions, you have reason to doubt the health of the working atmosphere in your team.
* * *
I hope you enjoyed your reading. If you want to know more about what makes an IT project successful I highly recommend you another book by already mentioned Jez Humble, this time in collaboration with Nicole Forsgren and Gene Kim ‘Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations’.
If you have any questions or need advice on your IT strategy, don’t hesitate to contact us.
