As the person with the CIO job, it is expected that you’ll manage an IT department that can successfully complete software projects in order to show the company the importance of information technology. However, this is not always the case. In fact, sometimes the software projects that our department are working on fail – and may even fail spectacularly. As the CIO it is expected that you will be the one who keeps an eye on things. When a project starts to get in trouble, it is expected that you’ll be the one who steps in and fixes things. However, you can’t do this if you don’t know what to look for. As the CIO, you need to make sure that you fully understand why software projects fail.
Having Too Few Team Members
I think that we all understand the effects of trying to do too much with too few programmers. We all know that there are only 52 weeks in a year and people can only grind out so much code before they burn out. A good example of what can happen when you have too few people working on a software project is when phases start to get scheduled back-to-back. Immediately when one phase ends, the next begins. The problem with doing this is that there is no relaxing. No thoughtful pauses that can be used to figure out what is working and what is failing.
CIOs need to realize that it’s very tricky to guess just how many programmers is enough. There are times that the plan is complete and the estimates are accurate. There will also be times that roadblocks and problems get in the way. It may not be the CIO’s fault that the job doubles in size but if you don’t have enough people on the job, your project is likely doomed.
Having Too Many Team Members
You would think that having too many people working on a software project would never be a problem. However, if too few programmers can be bad, too many could potentially be worse. One way to think about this is to realize that the very same network effects that makes some social media platforms so essential can also doom a software project. When you have more people, you need more coordination and that means more meetings, taking time away from writing code. It is possible to try to cancel meetings to give programmers more time to create, but if you don’t hold enough meetings, you’ll soon discover that Team A’s API doesn’t interface Team B’s API.
If you have too many programmers then they can sap each other’s time, sending the project into a swamp from which it never escapes. We all know that it would be nice if we could just throw money at a problem by overstaffing a project, but you can’t.
Making Fundamental Feature Changes
Remember the days when what a software project was supposed to do was set at the beginning of the project and then never changed? Nope, neither do I. That’s never happened. These days developers like to consider themselves agile. That’s why they love that word so much. However, sometimes agility can throw everyone off balance. When there is a change to a software project, it will depend whether the shift requires fundamental changes to the underlying framework. In the real world it’s easy to be agile when moving a button around or changing a color. This is not the case when it involves reworking the database schema or mucking around with replication, there’s no easy way to gracefully pivot.
Why You Pick The Wrong Technology For The Job
Choosing the right technology to use on a software project is hard to do in part because there are so many choices out there. Even if you were to plan carefully and draw up the correct list of features for the project, things may still fail if you use the wrong technology to build out the feature set. A good example are databases which are designed to be as general and flexible as possible, but they have architectural limitations. If you ask them to deliver something they’re not designed to do, you could watch them slow to a virtual halt when they scale. You may start off with a NoSQL database because they sound so cool only to discover later that you really need ACID-grade transactions to keep things consistent and the database doesn’t offer them. You’ve made a bad decision.
Poor Prioritization Of Tasks
Knowing what to do and when to do it is a key part of making any software project a success. We know that good planners draw up a list of features and prioritize them. The problem is that sometimes the priorities don’t line up with the reality of implementing them. All too often we discover that the most important features are also the hardest to create. What should your developers do? If they spend their time concentrating on the most important features, they will make no progress and may end up delivering none of the needed functionality. But if they start knocking off the easy ones, they may end up with something that’s worthless. CIOs have to realize that good planning requires more than a checklist. Your architectural vision must take into account the needs and the cost of delivering them.
What All Of This Means For You
In order to be a successful CIO, your IT department has to successfully deliver the software projects that they are working on. It turns out that this can be hard to do. All too often for a number of different reasons, a software project can end up failing. CIOs need to be aware that this can happen and we need to be able to step in, determine that there is a problem, and fix things. However, in order to be able to do this, we first have to be able to determine when things are going wrong.
One of the most common reasons that software projects fail is because they have too few people working on them. When this happens, we can quickly start to overwork the people that we do have and their productivity will quickly fall off. Alternatively, we may make the mistake and staff a project with too many people. When we do this the overhead of all of those people trying to coordinate with each other can slow things down dramatically. We’d all like to determine what a software project is supposed to do at the beginning and then stick with it. However, it’s all too easy for features to change in flight and these changes can fundamentally change the nature of the project. The technology that is selected for a project is critical to its success. If we get this wrong, it can slow everything down. Finally, knowing what order to work on the different parts of a project is key to the project’s success. The most important parts may be the most difficult and we need to get those done early in order to meet the end user’s expectations.
In order to be a successful CIO, your IT department needs to be able to deliver successful software projects. This can be a challenging thing to do. There are a number of different things that cause a software project to fail. As the CIO it is your responsibility to be aware of what can derail a software project, detect these when they start to occur and then take action. Understanding what it takes to make a software project a success is your first step in making sure that your IT department can be a success.
Question For You: What do you think is the right way to prioritize a software project?
Click here to get automatic updates when The Accidental Successful CIO Blog is updated.
P.S.: Free subscriptions to The Accidental Successful CIO Newsletter are now available. Learn what you need to know to do the job. Subscribe now: Click Here!
What We’ll Be Talking About Next Time
If there is one question that more and more CIOs are asking themselves, it’s what do women want at work? It turns out that the answer is the same things every worker wants: fair pay, flexibility and the ability to work on projects that fuel their passion and make a difference – not just in the workplace, but in the world at large. The person with the CIO job need to understand that if your organization also offers growth potential and boasts successful female role models on your leadership teams, then you’ve got a formula for attracting, hiring and retaining the best women technologists available today who can help the company with making use of the importance of information technology. CIOs have to understand how they can evolve their practices to foster an environment where women will both want to work and will thrive.