Evaluating Project Management software is a delicate matter, as it potentially involves changing deeply rooted companies’ habits; in general, this holds for all work management software. Being the subjects of such scrutiny, we experience that most companies fortunately take the right way right from the start, which is, trying the software, inserting in it some real project and people data, and seeing whether it works. In the case of Twporject, this can be done quickly, and there is both a demo online and an easily installable version, and considerable support readily available online to all.
But unfortunately not all companies take this “hands on” approach: some take the path of putting together list of requirements, and instead of testing the software against those, ask the software producers “whether their software meets these requirements”.
Now imagine that this was the way you chose to buy a house: you went to the seller, with a list of features, and you never go to actually see the house. You buy it because the seller tells you that the house fills your requirements. Nobody would do anything so foolish, no?
Putting together requirements and testing the software against them is actually a good idea, if handled properly: testing will at times show that the requirements are contradictory, or need refinement, and that the software models problems actually better than how imagined in the requirements. This is not surprising, as widely used software includes a lot of experience in management, often more than the users have. So the initial requirements should be only a first indication, and not something that is the main criteria for the final choice, which should be led by the usability and coverage or real problems offered by the software at hand.
Unfortunately there are producers of PM software and consultants that encourage users along the foolish path: they give formal answers to formal requirements, do demos themselves instead of letting the customers do that, make phone calls to facilitate over-priced sales, and all the usual bad practices.
Well, we don’t do that. We concentrate all our energies in developing a better product, and in producing publicly accessible documentation; we want customers to have software that really works and is usable, not just to close formal deals.
One can make software that satisfies long lists of requirements, but is totally unusable, will be hated by users, and will lead to user rejection, and hence to a huge waste of company’s money and people time. We really hope never to take that path.
Silvia Chelazzi - Pietro Polsinelli