The biggest problem today with IT projects is being able to bring them in on time and on budget. This is something we do every day at Dev Team Solutions, and we want to share in our experience of over 15 years of success in the industry.
In our view, there are 3 main reasons why software projects fail to deliver to deadline or budget.
- Over Engineering
- Over Resourced
- Poor Resource Management
Lets tackle these three aspects and see if we can help you with your IT projects.
No matter what IT project you would have worked on, it’s likely you’ll be thinking to yourself “why is this taking so long?”
The simple answer is that the project will be involving too many decision makers and we all know the saying “too many cooks”. Believe it or not, 9 times out of 10, you will have managers and team members over thinking the solution. Every meeting you have will involve a change to the requirements and the scope for the project will get bigger. In fact this can occur on any project not just within the IT industry. Scope Creep as the techy people call it is one of the key reasons why the project fails to deliver on time. Too many requirements and un achievable deadlines to meet those deadlines is a killer for any project. We’ve all been there, in a meeting that is supposed to be discussing requirement a, and all of a sudden all hell breaks loose and you end up spending a whole day discussing a,b,c, d and z.
As a manager and project lead of a number of years the easiest way to resolve this is to set clear and firm objectives to your meetings and to never deviate. If valid points are raised, note them down for further discussion. Within a project it’s important to break down smaller more achievable items of work. It’s easy to get swamped when trying to tackle a 6 month project in one piece. You don’t have to go the whole hog and go fully agile, but break the whole project down into each of its key deliverables. Then break them down into the things you need to complete the task. Allocate each task based on your teams competences. One idea that always makes me laugh is when a company tries to give new “exciting” features to the employee which jumps the highest. No No No. you are trying to get a project finished, on time and to budget. Tasks should not be allocated based on someone wanting to learn a new skill. Allocate tasks to the most competent person at delivering that task. If you have spare resource, by all means let someone shadow for experience.
During design phase, so many people will have ideas, and it’s important to listen, but don’t let that detract from the key goal of meeting that deadline. As a team you will think about all the possible scenarios that could or might go wrong, or what the user may or may not do. Try not to get bogged down with this. You will never think of all the ways a customer will interact with your site or product. Don’t over think, and don’t make it too complicated. If you think it’s too complicated, so will the end customer and MD.
We help so many companies especially in IT to understand that you don’t always deliver a project quicker by throwing more staff or money at the problem. Quite often more people means bigger budgets, slower delivery and often cause IT projects to fail. It’s not about quantity, it’s about the quality of your staffing and your resources that matters. 2 highly motivated individuals can often do the work of 10 underskilled poorly motivated individuals. Quality of skills is important, however the more people you have on your team the more communication difficulties you will have. Even with the best of intentions, having a large team can mean you as a manager have to make more people understand your end goal. Even when they do understand the project and the deadline, getting the whole team to work together like clockwork can be a nightmare. Too many people on your project and you’ll have more problems at the end of a project when trying to bring each of the elements together.
If one person on a task works at 100%, a second person will probably add only 30% at most to the task delivery due to the overhead in communication. You are better allocating that second employee to a different project/task. If you’ve done your project management correctly you’ll have a finite set of tasks that can run in parallel. That could be the best deciding factor on the number of people you use on a project.
In software, more people also often means greater discipline in ensuring all the code is written well and is understandable by the rest of the team. Most companies enforce this via coding standards. This slows down development and often no matter how hard you try, these standards will be deviated from, usually for good reason. This then means you need handovers of each of the modules in case of illness or someone shadowing the development. In the real world coding standards are a big time overhead and if you have a good time often achieve nothing. Spend more time on the important parts of team management. Ensure your team have everything they need to delivery their tasks without fail. Make them aware that they will have to work late if the project is late. Doing so in the beginning will allow them to plan the task so ensure it doesn’t overrun, or they will have to do extra late nights. No one wants that, so all effort is delivered up front.
Poor Resource Management
It’s a simple idea, and as a manager how do you know if you are managing your team effectively? The quick answer is you never do, but if you follow these guidelines you’ll probably be on the right track.
- Talk to each member of the team daily, but briefly
- Know your team members skills and weaknesses – don’t be afraid to ask them if they are comfortable with the task they have been given
- Always have an up to date plan of the project
- Breakdown your project plan into manageable 1-2 week deliverables
- Ensure meetings are quick and to the point – don’t get bogged down with questions or off topic discussions