How to make decisions while choosing a project in an IT company?

Question

Based on what criteria they choose the projects and what are the things based on which they choose a project...?

Answer 1

Return on investment, if they want to stay in business.

Answer 2

Return on investment is ofcourse the final product. But it takes a number of factors to get there:

*Their own expertise: Do we have people with skills needed to do this? Can we hire some?

*Available resources: Programmers, Managers, Hardware, Time, Financial resources.

*PR: Even if we dont get paid that much, will this project get us more business?

*PR: Pay is great, but do we really want to be associated with this client?

*Their Mission/Goals: What fields/niche do they want to compete in. Do they want to expand?

*Past experiences: We did a project like this, it was horrible. Lets not do that again.

*Past experiences: It was fun last time, AND we can reuse half the code! Lets do it!

Usually the management uses more sophisticated matrices and all to make their decision, but more or less, these are the factors they usually put in.

I am sure someone can provide a more specific/scientific answer.

Answer 3

Good question. The straightforward answer may seem to be Return on Investment (ROI). However, ROI is criticised for three reasons:

1. Short-termism: ROI is seldom calculated beyond 5-7 years (due to increasing discount rate on any cash flows produced in the future), some projects really worth doing realise full benefits much further in the future.

2. It’s hard or impossible to put monetary value on some things. The often cited example is human life. The other is moral principles. However, most frequently encountered thing in software world what is very hard to put a price on is opportunities that will never emerge unless this project goes live. It’s hard to put a value on the emerging opportunities, because we don’t know what they are until they actually emerge. And I don't mean opportunities that will simply not “open”, but specifically emerge.

3. ROI doesn’t take into account wider strategy. The importance of strategy in software world should not be underestimated and the strategy should take into the account specifics of providing software products or services. Geoffrey Moore’s “Crossing the Chasm” is a brilliant book I recommend and is very pertinent to the software world.

Joel’s recent instalment “Fruity treats, customization, and supersonics: FogBugz 7 is here” has a great sample of strategy document and the reasoning behind it. It seems that FogCreek plans to leave the bawling valley and enter the tornado (according to Geoffrey Moore’s classification) with their FogBugz 7.0 and hence the strategy of removing barriers that prevent people from switching to FogBugz, instead of spending time to introduce some more vertical features.

Other tools that can be used for selecting projects are SWOT analysis, Pareto analysis (i.e. choosing a project to address 20% of causes that are responsible for 80% of problems), PESTLE, Cost-Benefit analysis (similar to ROI, including the critique).

However, it seems that a sane strategy that states that the company is planning to do and not be doing in the finite period of time (often next year or two, in high tech market conditions are hard to predict beyond that horizon), gives a simple guidelines for choosing priorities and clear direction for joint efforts is the best starting point.

I also recommend reading a fabulous book “Almost Perfect” by Pete Peterson (former CEO of the maker of WordPerfect) that is available online. The book tells a real-life story of different strategies SSI Inc followed, some planned and stated and some ad hoc, and the way they were used to select what to work on.

Answer 4

ROI is only one measure. There are many other factors:

1. Risk management - for example, improving the process may not show any direct return on investment, but by adding e.g. unit tests the quality of the software can be improved and risk of a production bug reduced.

2. Compliance - there may be requirements by industry or government that need to be followed. Directly this may not show a return on investment because they may never be audited, but the downside to being non-compliant is huge (being shut down).

3. Manageability - providing metrics on bugs, project schedules etc. may not show a direct return on investment but it may allow them to better predict and manage their projects.

4. Security - this may be considered as a part of risk management, but it is a broad enough area to merit its own category. Making legacy code secure can cost a large amount of money and not show any immediate return, but there are obvious reasons why this is worthwhile.