How NOT to Run an IT Project

Practically everyone I spoke to was convinced that the app or tech solution that they had envisioned and in some cases developed was sure to be the ‘next big thing’ – if only they could attract an investor.

The experience was exhilarating to say the least – enthusiasm is, of course, infectious, but, invariably, I wandered away pondering two things about the approach:

1. Do you run your IT projects with as much bombast and over-excitement as you are talking to me now?
2. Is this how you are pitching your idea to the disbanded mob of suited and sour-faced investors that are crawling the stalls today?

Of course, everyone I met had clearly done well, were exceptionally driven, and I have no doubt at all that the attendant risks of failure that I’m about to catalogue did not apply to them at all. However, what did strike me were the inherent perils that could possibly occur in a dev house when blind enthusiasm is outweighing and perhaps even usurping the most important element of managerial correctness of them all – constructive communication.

Let’s now list some of the most common problems that can occur in a dev house, and what should be done to avoid falling foul to such errors.

Typical Development House Problems (and How to Avoid Them)

Meetings

Too much time spent talking, and not enough doing. Meetings – they can be useful in small amounts, but a dreadful waste of time if an agenda is not adhered to rigidly. A short, (strictly) 15-minute meeting might well be required before the work proper starts every day, but this should be just bullet points to ensure everyone is on the same page, and no more. We practise it at Netguru, too. A more thorough meeting once a week or once a fortnight can be utilised, but, once more, a strict agenda should be in place (see below).

Time wasted on irrelevancies. Of course, it’s a great thing when everyone in a dev house gets along swimmingly, but team meetings are not the place to discuss what happened over the weekend, or to make plans for the weekend ahead. Neither are they the place for professional digressions. The topic in question is the build at hand – not the latest innovation on GitHub.

Devoting too much time to a single topic. This is the classic. We’ve all been in meetings when a particularly hot topic seems to have everyone riled, and each person in the room has their own opinion on what should be done. This is no good, and, should this start to happen, the PM needs to step in and take control of the meeting. A solution should be decided upon, everyone must agree to it (whether they are in favour of it or not), and the meeting progress to the next item on the agenda.

Reopening already closed issues. This is another very common problem in the meeting room. Once a topic is finished with, it’s finished with. No ifs, buts or maybes. Once again, the PM or chair of the meeting needs to rein this in before too much time is wasted.

Decision stalling. The only way to progress is to make a decision – even if it’s the wrong one.It’s far too easy to contemplate one idea or approach after another, and then leave myself no time to actually write the thing. And the same goes for code-writing. Decisions need to be made so everyone can get started. If you’re using an agile approach to development (and you should be), then through the numerous iterations you will be able to alter the course at a later date should your work prove that you started off down the wrong track. But, first and foremost, you need to make those initial decisions and get working.

Lacking individual approach to the client. Not every project will work in exactly the same way. That’s just a fact. And that means you shouldn’t expect each and every one of your projects to follow a set path to completion because they won’t – and that’s also a fact. In the first instance, pains should be taken to ensure that the client’s vision is aligned with the dev team’s plan, which will be different with every new project that you take on.

Failing to predict potential obstacles. As the old adage goes – if you fail to plan, you plan to fail. No project will ever fly sweetly by without at least one hiccup to contend with along the way. But good practice dictates that you should spend a little time forecasting the potential pitfalls of a particular iteration. Time needs to be factored in to account for this, and alternative solutions should at least be thought of in advance so no one is left completely floundering when they hit a wall.

Inadequate mastery of project management tools. Great project management is at the heart of all successful projects. But, the PM can’t do it all alone. S/he will depend on the whole team’s mastery of the prescribed project management tools in order for tasks to be completed adequately and efficiently. Always ask your PM about the tools that are being used.

Communication

Agreeing to everything the customer wants, instead of opening a constructive dialogue with meaningful feedback. Ok, if it’s possible to deliver precisely what the customer wants every time, then great – go for it. But, the reality is that such situations will be unlikely – and even more unlikely that the customer will have the very best plan and ideas for the whole project from the outset. The client is not always king when it comes to development – which is why they hire a dev team to do this bit for them. A constructive dialogue needs to be ensured, with appropriate feedback flowing both ways.

Not motivating the team. Motivating your team is not an option – it’s essential for great end products. Believe it or not, project team members are human, too, which means that from time to time life will get in the way of a positive and enthused outlook on the work at hand. Motivation is important, but it needs to be done carefully and considerately, and I refer you to our post ‘How To Motivate Your Team: Naked Facts and Surefire Tips’ to get the lowdown.

Taking things personally. Nobody likes to be the one who got something wrong, but when you do, you should own our mistakes and look at them philosophically. The ultimate end goal is to create a product for which there is no rival, and sometimes that means that mistakes had to be made in order to find the best solution. This, indeed, should be the attitude adopted by everyone in the dev house – and PMs should lead by example.

We hope this post will help you avoid numerous traps that await your team on the way to launching another exciting project. Would you add any other pitfalls that might distract you from a successful project path? Share your thoughts in the comments!

Would you like to know more about the running of successful IT projects? Check out ‘10 Questions to Ask a Project Manager Before a New Project’.