These days I am in Doha, Qatar for deployment of a check book printing solution. It's an exciting project with a good mix of technologies: an NCR kiosk with touch screen display, a Rototype CBD1000 machine that will print checks and bind them together; integration with the backend systems (MS SOAP Toolkit 3.0 and Oracle stored procedures) and the best part is that it's bilingual - English and Arabic - what else would one desire?
(As a side note, my company, Avanza Solutions, is better than its competitor in many ways; the most important difference is our aggressive nature. They being older in the market are now mostly supporting their products only. We, on the other hand, are open to changes/ enhancements in our products.)
If you ask me what is the most difficult part of software life cycle, I would say, "Going Live!" Somehow, software deployment takes as much time as development. Ideally one would like to have one button to click in order to deploy software! So what exactly are the gray areas that take so much time?
The problem, first of all, lies in the attitude of developers. Only few write code with a user in their minds or more specifically with the notion that it has to go live. Almost every developer that I have seen to-date takes software development as an exciting problem solving activity and never looks into those areas of the problem that seem less exciting (like security, exceptional cases, wrong input, performance issues, testing on a different environment, etc.) Since all such issues must eventually be resolved in order to go live, a lot of activity just before deployment is related to these ignored areas.
Secondly, for every piece of software to run, there are pre-requisites - like a database, service packs, a particular version of web browser, etc. Usually, the responsibility to provide these lies with the customer. However, due to the fragile and intangible nature of software (and the dear customer being naive in general), the customer expects the deployment personnel to set everything up. I am not sure how we can change the client's attitude but they say that if something is inevitable (your software sure has to go live, right?), you are better off by being part of the change rather than resisting it. After all, "whose project is it anyway?"
On a related note, I have observed a very interesting characteristic amongst human beings - if you volunteer for something, everyone thinks that it's your responsibility to lead.
So what's the point? The point, "go out and take over project management" - even if it's not your responsibility. Once you volunteer for the ownership, people will expect you to help them out - even seniors and those who don't come under your supervision will accept you as the boss!
However, there is one particular situation where I'll advise you to roll back instead of taking up the ownership: when the customer is least interested in the solution. This frequently happens when it's a low cost project or when it's merely a presales activity. Be very careful how much time to spend on a pre-sales activity and how much interest the customer has.
Deployment and software support are the most boring part of the software development life cycle (SDLC). At the same time, they are what everything else is all about. While one person might be waiting for hours for an IP to be assigned at the client side, other developers might get assigned to a brand new, exciting project. A software house should help its support engineers by improving their morale and appreciating their patience and diligence - a bonus per deployment shouldn't be surprising - after all the company gets money when the software goes live.
Isn't this gone a bit lengthy? Actually I have been waiting for more than 2 days for the client to find the keys to the printer that he has managed to loose! Software deployment is boring. Would you bet otherwise?
Limited in his nature, infinite in his desire,
Man is a fallen god who remembers heaven.
(Alphonse De Lamartine)