Cool Solutions

Pros and Cons of a Rapid Deployment


April 13, 2006 2:49 pm





In my previous entry I mentioned the scale of this project – 15 sites, 50 servers, 2000 users and six days. The only way that this could be achieved was using Rapid Deployment.

Most projects are broken down into a number of key areas; at a high level these are:

1. Requirements Analysis
2. Proof of Concept (resulting in initial design)
3. Detailed Design
4. Lab / Pilot implementation
5. Design updates
6. Live pilot implementation
7. Go Live

For Rapid Deployment a number of these steps are removed. No, scratch that: most of the steps are removed. In most cases a Rapid Deployment will involve only steps 6 & 7.

And this is RISKY. With a capital R.. I.. S.. K.. and Y!

Why is it this risky? Well, in short the risk is because for a Rapid Deployment you will be working ‘live’. This means that any changes made during the project can have direct impact on day-to-day use of the systems. Also, any problems encountered during a Rapid Deployment will need to be sorted ‘on the fly’ – options for troubleshooting are greatly reduced with the absence of a lab to test in.

So, are there any guidelines for a successful Rapid Deployment? Yes. In my opinion there are.

a. A stable environment. Ensure that the network/servers/workstations are all up to date with the latest patches and updates
b. Knowledge of the environment. This is critical. There should be people on the project who know the systems inside-out. In my opinion this was one of the major contributors to the success of the project
c. Knowledge of the new product being deployed. You will need experienced consultants/specialists who know their products from the ground up and are experienced in deployment.
d. People with the ability to think on their feet. There will be problems and design changes during a Rapid Deployment. The team need to be albe to think outside of the box to overcome these challenges.

If you have all this lot then you should (notice I don’t say ‘will’) have a successful project.

So, now with that out of the way – see it as a kind of disclaimer – we can get onto what happened. My next three posts will be a day-by-day account of the project and how it went.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.


  1. By:devn3t

    I’ve done 220 PCs on a network in 2 days. I imagine it’s possible to do 2000 if you add a few more project managers.
    I did these installs about 15 times a year. I also did them with temp technicians who had never done it before. I think that if you added about 4 more project managers, 2 more networks and 4 more days, you might be able to hit 2000.

  2. By:scbdam

    I’m not sure that this is the point of the post – Laurence is talking about the pros and cons of RAPID DEPLOYMENT – not normal upgrades.

    220 PCs in two days isn’t really a challenge. Creating a design in two days to rollout 2000 upgrades is!