Why your IT project failed? Part 2

By Andreas Maratheftis on Friday, 14 of March , 2008 at 10:51 am

This is the second part to the previous post regarding the reasons IT project’s fail.In the previous post i mentioned the general reasons,which most of the IT projects from small sites to enterprise applications have in common.
The second post focuses on the little things. Small misconceptions that if you add them up can make or break an IT project.
All team members have responsibilities within a project, clients, employees (developers in this case) and managers.

Clients will always chase you up on the progress of their software. That is why they are paying you. Avoiding them and providing wrong excuses does not help. Clients dont understan software, in their minds software projects are like building projects where you have fixed resources and variables.Software is not like that. Take time to explain and be honest.

Don’t be greedy.Don’t try to get as many projects as possible. You are in the business to make profit, true and that is a valid point. But at which point does customer satisfaction come in? At which point will you as a business realize that this is the limit my current resources can take, this is the number of projects i can deliver at that specific time line. A lot of company owners get the work but none of that gets delivered on time and on budget simply because their developers where too busy to follow up on other projects or left some tasks unfinished.

Something else that i have experience is the trust between management and employees. Managers should listen and trust their employees. I have seen a number of managers doubting software estimates from developers. This is not always correct.I am not saying you should not question your employees estimates-but at least make sure you understand why that estimate is so high or low. Also developer’s should carefully considered what is involved when producing estimates based on user stories/requirements and request from the business analyst more detailed specification if required.

Client’s do play an important role. If you as client are not practically involved as a member of the team,then this means that you are not really concerned to what will be delivered and to what quality that piece of software will be. It would be a good idea for you to know as a summary what your business needs and requirements are and ensure that you provide feedback and any relevant material required to make the task easier. The clearer the requirements are the less problems will be down the line.

Priorities is a major issue during software development. It’s not really about prioritizing requirement’s. There are plenty of tools to do that. What is difficult is prioritizing projects and managing your client’s expectations. If you say to your client we will deliver your project on the 31 July, the client will expect the project ready to be tested on that date. If you have a trillion other projects and clients expecting projects “yesterday” then you will never be able to deliver any of those projects in time. The solution here i suppose is to explain to the client the difference of software projects to other engineering projects and make sure you provide estimated deadlines and provide to your client on-demand and as often as possible progress reports on their project.

Incentives. Employees like to be appreciated and to be considered as an asset of the company. Incentives are always very welcome and promote the sense of a friendly competition within the team. The employee of the month does not work anymore.When i mean incentives i don’t mean money. People in our field are usually hungry for knowledge; send them on a 5 day training course or an IT conference, even on a day out with the team, these little things can build up strong realtioshinps within the team help to bridge communication gaps, build a sense of commitment. It’s amazing how the people around you help you to be more productive.

Invest in your employees. In our field constant education is must. Investing in some training courses for your employees (and probably for yourself a a manager/business owner) is always positive. You will see the returns of that instantly.

I think i have covered a number of topics.There are of course more to this list.

Category: Business Analysis, E-business, General Web, Software

Add this post to

Del.icio.us -

Meneame -

Digg

1 Comment

Made Thursday, 26 of July , 2007 at 2:54 pm

Hi
Nice post. Both part 1 and 2 are valid.
All members participating in the project do have responsibilities.
However you failed to mention that responsibilities differ.
The part regarding managers is interesting.
Managers should be the 1 person where all other team members will turn for guidance. A manager should lead from the front. It is like managing your army, if the general is missing or is unable to manage,who will manage the troops? The sergeant? The manager should be the one point of reference for everyone in the team.
The part about incentives is true. It is a fact that in big companies that have bonuses,or profit shares, etc employees are loyal to the company,put in more hours and deliver projects better.
Good to mention here that developers and other project members,project managers,business analysts,sales people,graphic designers have different responsibilities. These do depend on resources as-well. If you spread your resources too thinly(e.g IBM) you will eventually fail to deliver your projects on time.
I suppose companies should really turn around and ask the following:
1.How many projects did i take until now?
2. How many of these projects were delivered on time?
3. On budget?
4.On quality?
5. Was my customer satisfied by the project? (satisfied customers will return, no matter how big or small,if they don’t then they were unhappy with you)
6.What did my people get out of this project? etc..

Thanks.
Sorry for the long post…
Pedro