1.4 Ready, set, tailor

As IT professionals, tailoring systems from scratch is not just a challenge but a significant responsibility. It’s well-known that over two-thirds of such projects fail to deliver the expected results. However, we must focus on the set of capabilities and traits that distinguish successful projects from failed ones, and this is where your expertise and dedication come into play.

Projects are set up for success or failure before they begin. The activities done during the project can rarely save you from total failure if you prepared the project incorrectly. However, it’s important to remember that you, as IT professionals, often have the power to select technologies and vendors beforehand, empowering you to set the project on the right path.

Startup companies have the luxury of doing clean-room implementations where they don’t have to interface with decades-old IT. They also typically can build tiny integrated development teams that don’t have to take part in the rites and activities of a larger corporate environment. Not surprisingly, startups usually finish their software, and the business swims or sinks.

Larger enterprise environments are vastly different. New systems are often required to interface with old solutions, and the development teams have formed during a long history of projects. Business personnel most interested in development will lead the implementation, and the IT department forcibly injects layers upon layers of quality requirements and secondary activities into the projects.

Overall, adding more developers as software projects grow in enterprise environments tanks the performance of single developers. After something like 10 developers, adding 5 more doesn’t add +50 % capability to deliver, but perhaps only +25 %. After 50 developers, 10 more added might yield as little as +5 %. The overall activities of most enterprise environments will not scale up.

Most large organizations are still hierarchical, and their organizational charts look like pyramids. Software development teams having to make escalated decisions will cause a collision between a fast development cycle and the millennial tradition in bureaucracy. The solution is building empowered, self-sufficient development teams responsible for (sub-)products.

You are not operationally responsible for the software development process as an architect. You will advise on how to set up the teams since you chose the core technologies and participated in selecting the correct playbook. In part, your task is also to ensure the team structure adheres to good practices. What you want to look for are people, skills, leadership & management, and the level of dedication.

You want to ensure your team has previous experience with the chosen technologies or equivalent. For the combination of Java, React.js, and PostgreSQL, you ideally want to see those in the developers’ work histories. If a vendor has worked on, for example, another modern, heavily component-based JavaScript framework, you may consider that equivalent experience and sometimes even reconsider switching.

You want to make sure you have the correct amount of developers. If the system has separate areas of functionalities for different user groups, it might make sense to split the development into individual teams. A good team size is between 5-9 developers because that’s with how many people the average human can maintain meaningful social connections. Remember that you will have one or two extra roles, such as the product owner and the architect.

A Scrum master in agile development plays a crucial role in ensuring the standardized rites function, and that the Scrum model is followed. Contrary to popular belief, a Scrum master is not a project manager or a full-time role. It should require about 15 minutes of work daily. The daily meetings should go like this: ‘Who has problems? I will coordinate resources for solving that. No one? Good, do your work.’ The scrum model will never have a project manager.

Waterfall projects, a traditional software development model, should have a project manager. A significant part of development in waterfall projects is ensuring the development team implements every requirement. Waterfall projects rarely have many optional requirements, and the process for testing and accepting deliveries is the main process engine of waterfall projects. The software development model is one ticket per pre-defined feature or quality requirement, and an engineer implements it.

Sometimes, a software project requires input or decision from a specialist. For example, an accessibility specialist may test all the software developed by several teams and may not always be available to serve a single specific project. Most software projects move a lot faster than the rest of the company. You have a significant issue if the software project can’t proceed waiting for the specialist. And no, you will never have every specialist just waiting for your project’s work.

The recommended solution to the previous is to design those areas of development as funnels. A funnel in software development is a process where you start with a broad set of requirements and gradually narrow them down as the project progresses. You should have a preliminary chat about the topic with the developers as early as possible. Knowing the requirements, the software developers will fine-tune their goals and automatically produce something that will more likely pass the later and more thorough testing. Then, you order a few reviews along the way. Carrying on the development sans the final verdict isn’t a significant issue.

Select the management tools used by the teams. You need something that can capture good ideas before they are lost, something that can track tasks that they get done, and something for producing technical and end-user documentation. Atlassian products are popular in enterprise environments because middle managers like them. You can choose Post-it notes and something like Mediawiki, too.

The traditional view in enterprise environments is that the business side gives money to develop systems. They often want to instill their leader into the project to ensure the mandate to use substantial money. They also provide product owners with a deep understanding of the business goals and the processes the system is supposed to support. While the selected personnel are typically IT-enlightened, they are far from software development professionals.

Understanding the basics of IT and project management is crucial for business leaders and managers involved in software development. By providing training for these roles, you can ensure they have the necessary knowledge and skills to effectively lead the software development project, making them feel more confident and competent.

The most common pitfall I have seen is attempting to perfect the software. Staying in one development area for too long means your project will never get to the rest of the software. Also, business leaders often want the earlier described pyramid-like decision structure, which will stall your software development. These are the easiest pitfalls to prevent if you train the business personnel before the beginning of the project.

If you think software developers’ availability is good in the current market and we don’t have to compete with the vendors, you are incorrect. You will always have to compete for the most capable talent. The most capable talent chooses whom they work with. You must select a suitable technology stack, the correct playbook, draft team composition, and train your personnel to make your case more interesting to the best vendors and the top teams that pick their clients.

The difference between a great talent and a mediocre one is vast. Mediocre programmers primarily focus on job security and meeting minimum requirements, often approaching programming as a routine task with little initiative or passion for improvement. In contrast, the best programmers genuinely interested in developing good software are driven by a love for the craft, prioritizing quality, innovation, and continuous learning. They proactively embrace best practices, new technologies, and challenges, striving to create impactful, maintainable solutions. At the same time, mediocre programmers resist change and adhere strictly to established processes without seeking growth or excellence.

Of course, in-house software development is an alternative to vendor outsourcing teams. It requires skills and capabilities to attract and retain skilled software development specialists. It’s much easier for startups and more complicated for large enterprises. Ultimately, the same applies—you must have interesting problems and well-thought-out projects to attract the top talent.

Everyone wants to participate in a project that is an obvious winner. Only the mediocre teams settle in for losing projects. If you can live with mediocrity, implement your strategic major initiative using that. You will end up as a blip in the statistics of the failed projects.

While your environment probably also has others working on setting up projects, you, as an architect, are expected to do your part. You want to see the correct skills related to your project’s goals, and you need to make sure you set up the project to run using the correct leadership model. You also want to ensure you train the inexperienced personnel participating in the software development project. You also want to ensure your project attracts top talent, especially if the project is critical for the business.