Tags: | Categories: Blog Posted by admin on 3/9/2009 5:56 PM | Comments (0)

If you have been involved in a release of a big system, you'll understand what I am talking about and what I am coming from. When I talk about release and implementation I am describing a scheduled implementation that will take more than one month on the client side with applications servers, database servers, web servers, web services, load balancing and SAN clusters. Then the deployment on a customers side becomes a little hairy as they are lots of variables that can go wrong and do believe will go wrong. Besides the implementation time and being on side, you'll have to follow the new rules implemented by your customer on side. If that's no enough, you'll have to go step by step to make sure that each system, software, COTS and configuration is completely transparent to the customer. Some good customers, purchase the source code, so training not just in the application has to be provided, allow yourself another 2 weeks of training as least.

This are the step I follow and I learn to follow from project managers, release managers, QA managers and implementation managers. I have to be honest that not always I follow all the rules, but every time I brush one aside I regret the decision, also I want to disclose at this time, that I am not an expert on software release, I am a geek software engineer that loves coding and challenges, still I observe release managers and I learn to implement their procedures and follow their instructions, by doing that, with ease I'll be successful at my job.  

  • A big software project is not just gathering the requirement and providing with a time line, you should also looks how will be delivered and who will be in the team for the client side. This is important as the DBA and system engineers that will help you while you onside because part of your team. Also write down any customers restrictions, travels, timelines, hardware and software license.
  • When collecting the software requirements check for any requirements that flags out a showstopper or you are not sure yet how to accomplish that task. If you don't, when trying to fulfill the requirement later will be too late in the game and the money will be out of your pocket. Remember you are not giving research and development, as the customer already signed.
  • Involved QA in a very early stages of the game, don't wait for the application to be on alpha release, start testing the parts completed, even if not working right yet, at least they'll provide you a to do list for your to finish.
  • Set milestones; not just to get paid by the customer, but to get step by step as mini applications and keep adding a milestone at the time. Do know go back and forward the milestones because is easier to fill a requirement now you writing something similar.
  • Force the complete internal releases, where the application is complete deployed once every x days, weeks, months. Do not wait to finish a feature, just release and let it go through the whole process from the beginning to the end. Will train the whole team. Use Microsoft Team Foundation Server if possible.
  • Bring subcontractors and COTS in the beginning, not in the early stages of development, they should be finished before you start writing code if possible, don't get yourself in a bad position in the event that a subcontractor cannot deliver what promised at dead line. Be realistic, how many projects finished in time? So when you got 20 subcontractors get their projects finish before you start your. Then implementation will be easier.
  • Learn from other people in your team and adapt to their ways. On your team will be good and bad people in your opinion, not everything is black and white and let people do their job and observe the result. Of course, if you are in the position to be responsible for their jobs, you may want to provide guidance and a deadline to allow time for you to clean up messes, and I promise you that messes you will clean up in any project and in any position.

So this is what I learn so far and the items I took by observing different position and projects. I'll revise the list every year, hopefully will grow, likely will change and adapt, hopefully will improve.

Cheers

Al

blog comments powered by Disqus