Software Guide

Wait a minute… why should all software projects be stopped? Isn’t software helping us do more, faster and more easily? True, but the problem here lies in the word projects. Generally speaking, projects have a temporary nature—with a beginning, a middle and an end. Investing in software, on the other hand, is an ongoing commitment. Once a company makes the latest version of software available to the user, defects in the software need to be fixed, new features added, new security threats mitigated, and stability and speed improved, as well as many other tasks.

Projects or products? Mixed teams—made up of business and IT personnel—need to move from software projects to software products or even to wider business streams (more on those below). But why is it better to invest in an ongoing product than complete a succession of software projects? In my experience the main issue is that the project is too narrowly focused on implementing the defined features. Meanwhile, the overarching goals of software quality are often neglected. The project head does not wish to use any of the limited budget on improving maintenance for the IT support team, for example. The same dilemma can be repeated over the course of multiple projects. Gradually, the underlying software foundation becomes less and less suitable for supporting all the features added on top. This means that every new feature becomes harder to implement because the code is a mess!

Creating chaos A further problem I’ve encountered with larger companies is the way that software projects are funded and steered by various business departments—each with its own set of goals. They may have their own business terms or be unfamiliar with the terms used by other teams. This kind of scenario makes everything drift apart—and ends in total confusion. This happens when there is no central product team to make sure things stay aligned.

Projects may also suffer towards the end of the financial year when budgets run dry, and new budgets still need to be finalized. The customer is not having a one- or two-month break though.

The trouble with time reporting A friend of mine described the issue he recently experienced whilst working on a large IT system. Multiple projects were all running at the same time. The company had invested a lot of time and money in recruiting talented software developers, only to entangle them in budget battles. The team members were asked to write down exactly which project they were working on. As the projects were somewhat chaotic, this friend and other members of the team constantly had to switch between tasks and keep track of each call and deskside visit, depending on the project they had to report on. They lost about 20 minutes per day reporting on countless minor activities, as well as on which feature they were working on. This frenzied activity was a real pain, and it greatly reduced productivity. After the software teams had complai¬ned about the situation for weeks, the business side eventually agreed to stop the nonsense and allow them to simply book their time on the product instead. This problem is actually a lot more common than you might think. In nearly all the projects I’ve been involved in during my professional life, no clear definition was given of the level of detail expected in time reporting.

To charge or not to charge Another issue is that some teams in companies work “for free” (no charge to the project) and others not. This leads to strange decisions. One of my clients charged the internal test-automation team for instance, but didn’t charge projects for manual testing. Accordingly, most projects decided not to automate any of their tests even if some automation would have been highly beneficial from a company perspective.

Business streams An alternative to product thinking is to focus on business streams such as customers or products, for example. The business-stream focusing on products would be responsible for product-related systems. The decisions would then be above individual software products, and relate instead to the business areas as a whole.

Ironically, my recently published book is entitled *Guide to Software Projects for Business People*—the term is so widely used that I couldn’t think of a better title which everyone would understand.

You can purchase your copy here: https://www.amazon.com/Guide-Software-Projects-Business-People-ebook/dp/B07MMYZB4B