If managers ever estimate a project’s value, they usually go by costs — how many man-hours will be spent, how much equipment will be needed, what business trips they will go on and where, etc.

However the cost evaluation does not really show, if the project is worth spending money on in the first place. This particularly applies to the teams that are used to do everything in the proverbial two weeks (and are of course never as good as their word).

Let’s take a little break from estimating our costs and try to look at our project as an investment. Not all of the IT projects will fit this pattern, certainly, but we will be able to work on some typical cases.

Both developers and testers are too clever for their own good. To them task that says “Just make everything work” is a challenge rather than an insurmountable obstacle.

Users on the other hand are usually sceptical. They are not the least bit inclined to solve puzzles when they’re just getting acquainted with a system. Sometimes, they resent it so much, that it turns into a full-on sabotage of your project’s implementation.

So where is that entry threshold? How does one estimate that scope of failures? What needs testing, if anything? Does that “little thing” really affect the product quality?

Let’s look at some examples and discuss practices.

If managers ever estimate a project’s value, they usually go by costs — how many man-hours will be spent, how much equipment will be needed, what business trips they will go on and where, etc. However the cost evaluation does not really show, if the project is worth spending money on in the first place. This particularly applies to the teams that are used to do everything in the proverbial two weeks (and are of course never as good as their word). Let’s take a little break from estimating our costs and try to look at our project as an investment. Not all of the IT projects will fit this pattern, certainly, but we will be able to work on some typical cases.

Sometimes project managers use their analytical skills for internal purposes only. In fact, everyone but project investor gets possibility to discuss feature requirements properly. Moreover, the investor feels himself not so comfortably, if it is necessary to communicate with project team and to make some decision about analytical data. Is there a way to understand wether your customer or investor understands everything he needs about requirements? How to involve him into project? Why and what for? Let's discuss our experience together. Early adopters are strictly welcomed on the talk show.