Scope of IT projects

In the last weeks I have worked very hard to finish a project in time (where I did not have a real influence on the deadline) - and this by the way was also a reason for not posting here for a while.

I finished in time but most of the others didn't. And one of the reasons (besides others): Unawareness of scope and impact of the project.

I remember times when (at least smaller) companies had to be introduced to computer basics when I brought the developed software because prior to the installation of the new software and hardware there was nothing - nothing computer related of course.

Current IT landscape is far different. Each piece you are going to change affects plenty of others (and this might be the crucial factor why many companies still stick to full Microsoft product stack hoping that at least that works smoothly ;-) ). When designing new software you not only need to think of the software features itself but also of the (possible) environment where it is supposed to run. And according to that, the appropriate interfaces need to be present. APIs (Application Programming Interfaces), links to other well-established software packages, (automatic) sync and import/export features are not a gimmick any more - they are required parts for a new software piece. Otherwise the thing can't be plugged into the existing stuff. But most serious software products nowadays do consider this situation.

Let's talk about "processes" - a very "consumed" word these days: At meetings I often can observe a lot of thoughts, ideas, issues and uncertainties thrown at the table at the beginning and then after a certain level is reached that nobody can get hold of the whole thing any more, somebody states (trying to get to an end of the meeting) something like: "We need to analyse the processes (now)." Of course the processes or work flows are a tipping point. Companies should know them or at least analyse them before. When starting to analyse the environment and work flows - the processes are often very different in the reality from what I get told initially by IT or management.

While in projects related to SAP it is normal having a planning phase during at least a year, for most smaller projects the teams do not invest into analysis at least a few weeks or not even a few days.

Another big pig in IT project management: Assumptions and interpretation. Source of huge creativity is the sketchy documentation or just quick look at designs or prototypes. In documentations there might be unclear statements. People often tend to interpret (and discuss interpretations) rather than clearing up the situation by investigating the facts. At the beginning of a disaster there is always crappy guesswork!

And it comes to ignorance: Even on projects where prototypes or demo versions have been set up at the client months before switching production, I experienced, that nobody was really examining the demos and prototypes and then they wondered because of unhandy GUI or whatever.

So we get to implementation: I don't know if it is because of economic crisis that software testing efforts are reduced or if it is not the testing effort but the increasing complexity of software - or both, fact remains: Software nowadays to me seems to be more buggy than 15 years ago - generally spoken. But this means that software should be tested more than ever. That said in reality the implementations often get late and to keep deadlines, testing is done only on the surface.

You may wonder if it could be still economic to set up a new IT project looking at the general situation in IT and with software. I say: Yes, there are a lot of processes ;-) that could be drastically improved with the aid of IT and computers. In reality IT has grown to a crucial backbone of most companies during the last 15 years - they simply can't to without any more. And so, it is more important than ever, doing precise planning and good quality work (not only when it comes to software).

Related posts: IT project costs explosion, Economic crisis and IT, The small software vendors.

Firefox change default page format

I live in Austria and standard paper format here is A4 and not Letter.
It is very annoying that Firefox does not remember the page format once I changed it in "File->Page Setup...". If I would use the german version of Firefox maybe defaults would have been set to A4 anyway - however in the english version (at least on Ubuntu Linux) the default is Letter.

Here is how to change it (to A4 in my case):

1. In the location bar enter: "about:config"
2. Read carefully and confirm that you are going to be careful
3. Be careful with the following steps!
4. In the search bar enter "paper"
5. Look for properties ending with paper_size and paper_name.
6. For me it was sufficient to change "print.postscript.paper_size" and "print.print_paper_name" to "A4".
7. There might be some additional properties ending with paper_size and paper_name for each of your available printers. I didn't touch them and it worked anyway - YMMV.

HTH.

Related posts: Locale configuration on Ubuntu, OpenOffice and LibreOffice starts slow, Default Paper Size in Open Office, Normal.dot in OpenOffice or LibreOffice.