Software Deployment

Managment folks like to make nice and tidy numbers but really it comes down to what your process is, what your SLAs look like and how well you are hitting those SLAs. Some places I've consulted have 8 packagers for 3000 desktops meanwhile I know of shops supporting 21,000 users with four packagers.

The deviation really comes down to process and scope for the packagers. Some have to perform the application architecture while others get completed documents with full implementation and brief testing instructions. Some shops package everything even if it is only for one user and then others require that it must go to more than 10 desktops to justify the overhead of putting the application into a managed environment.

The places that have had the best success with right sizing the staffing levels have been shops where there are experienced project managers that can take a process, calculate realistic metrics and determine if the manpower at hand can handle the workload without affecting service levels. You would be supprised at how few companies have such expertise on hand.

The places that have had the best success with right sizing the staffing levels have been shops where there are experienced project managers that can take a process, calculate realistic metrics and determine if the manpower at hand can handle the workload without affecting service levels. You would be supprised at how few companies have such expertise on hand.

No, actually I would NOT be surprised at how few companies have such expertise on hand ;-).

To fill you in a little more on my specific situation:

--We generally don't repackage for fewer than 10 users; however, because we're such a large organization, finding 10 users who want a particular app is very easy. So, the practical upshot is we repackage practically everything that comes in.

--We don't do a lot of the application development/architecture work ourselves (don't have the manpower/resources), but we do a fair amount of custom actions/vb scripting within the MSI and/or MSTs themselves for various reasons (custom permissions, region-specific configuration, starting/stopping services, etc.).

--In theory we're supposed to get fully functional completed documents from application project managers for installation & testing. In reality, what we get is rarely useable/current, so much time & limited resources are spent chasing after PMs for corrections and missing information. I'd love to change this situation, but this is the reality for now.

However you want to slice it, though, I'd say we're critically understaffed by any reasonable standard. Thanks for your comments --very on the mark!

Well I am in almost a similar boat as you. My situation right now is to have meaningful statistics relayed to management so that they can understand what is happening at our level. The problem of having insufficient technical documentation before packaging an application is that it makes your process looks like a drawing done by a three year old with coloured markers and horribly complex to report on.

A part of the answer depend of how much you want to package? Here we are packaging everything install on every computer. We have 1200 computers and then 4 part time packager (usually only 2). Nothing is install on a computer without packaging.

There is no "proper" ratio, many many many factors play into the ratio. ...But you CAN make a man-hours calculation.

You already have a packaging process in place. Assuming that the efficiency of your process is acceptable and won't be radically improved, look at your historical performance and determine the [Actual Avg Man-Hours Per Request]. Don't count time spent waiting on others, just the average # of hours that 1 person actively worked on fulfilling the packaging request. If 2 people work together for 1 hour during the process, that's 2 Man-Hours.

Look at that number. Does it make sense? Is it too high, indicating the packaging process efficiency could be improved? Is it too low, indicating that quality suffered by rushing packages out the door to meet SLA requirements? Use your gut instincts to adjust [Actual Avg Man-Hours Per Request] and determine your [Ideal Avg Man-Hours Per Request].

Then crunch the numbers.

[Ideal Avg Man-Hours Per Request] x [# Requests per Week] = [Weekly Packaging Workload in Man-Hours]

[Weekly Packaging Workload in Man-Hours] / [Hours in Work Week] = [Staff Count to Meet Workload Demand]

Then you can start manipulating the numbers to come up with other numbers.

[Current Staff Count] x [Hours in Work Week] = [Current Man-Hour Capacity]

[Weekly Packaging Workload in Man-Hours] - [Current Man-Hour Capacity] = [Current Weekly Man-Hour Deficit]

Since the Man-Hour Deficit must be taken out of QA if the packages are to get out of the door...

[Current Weekly Man-Hour Defecit] / [# Requests per Week] = [QA Man-Hour Defecit Per Request]

This means that the reduced packaging staff results in [QA Man-Hour Defecit Per Request] saved Man-Hours per request. Management will view this as a good thing. BUT... Then compare that to Man-Hour cost of supporting the packaged application over its lifetime.

Here's where a ratio comes into play. Calculate the ratio of Packaging Request QA Man-Hours to Support Man-Hours. The results there can be surprising. Every Man-Hour saved in Packaging QA can cost 100+ Man Hours in support. That'll get management's attention! [:)]

At my shop we have about 2000 user and 1 1/2 packager

Linstead,

Do you have a midget packager in your shop, or is the packager really, really big? [:D]

LMAO
But serioustly now...
We have 2300 users and just one packager ( well i'm really only a half cos im always hitting brick walls :( )

From experience:

First packaging contract: 2 packagers for 400 users. Packaging made up 60% of our total duties (we were also just standards support techs).

Second packaging contract: 5 packagers for 2300 users. Ours was the "engineering group". We did software packaging, SMS administration, starding image management, patch management, high level desktop support. We were basically the guys that did all the hard stuff on the desktop side.

Current contract: 1 packager for 2800 users. I do packaging, GPO deployment, and AD & GPO administration.



My duties are expanding daily, so we'll probably be grabbing a second packager soon.

My current contract = 2000 machines = 1 packager (me!)
Previous contract = 20,000 machines = 12 packagers (weren't always flooded with work though).

M

I really appreaciate all those who have posted estimates & suggestions.

Francoisracine - We too package everything that goes on the machine, even Active-X, IE, plug-ins, etc.
VikingLoki - I totally understand what you're saying, but such a detailed analysis assumes that management will spend the time necessary to read/interpret it (not likely). They want quick & dirty numbers/estimates --period.

So far, here are the rough ratios, as expressed in # users : 1 (FT) packager:

my company 20,000 : 1
kkaminsk
1st example 5,200 : 1
2nd example 375 : 1
Francoisracine 600 : 1
linstead 1,333 : 1
dbowe 2,300 : 1
Bladerun
1st example 200 : 1
2nd example 460 : 1
3rd example 2,800 : 1
MSI_repackager
1st example 2,000 : 1
2nd example 1,667 : 1

I have one more modest request: Would any of the above posters be willing to share the name & city of these companies with me privately/offline (email)? I'm not asking for YOUR real names or specific building/street addresses, just enough info to pretend I didn't completely pull these numbers out of my ass ;-).

Thanks all...

We currently have 16 packagers working full time to package for 30,000 users. This seems to work for us because we have packagers woring on both project work and also BAU stuff. Mind you I have been so busy I havent been able to post here for a month or so...so maybe we need more people on the team :)

I think the main resource that the business uses extensively is the actual platform knowledge that is in the packaging team.

If you don't know the platform well then it actually takes longer to package apps that provide the end user with the right experience.

For instance we repackage all apps so that they can move through the environments we have set up DEV UAT and Production. One package must work in all environments without change to get to Prod. This requires knowledge of things like server connections etc. across the whole Enterprise. that sort of knowledge is what makes for more productive and quality work regardless of how many people are doing the work

We have a good certification process too... I believe
1. the packager
2. In the lab a second technician examine the scripts, send the package with SMS and test all scenarios (installation, uninstall, migration)
3. In preprod, a third "specialist", send again the package on many computers and with someone having a good knowledge of the software test the software with a restricted account (a user account with no rights).
4. An analyst examine the documentations, scenarios and authorize the product in our environment.

Only after that we can use the software in our environment. It is a long process but by doing so, our environment get more control and is more stable.

The downside is the management find it very expensive... and ask us to find a way to make it less expensive... I am not sure how we can do so because it is rare a product will pass through all certification level the first time...

Norexx.

All above might be true but I'll give you the way it is here. One repackaging engineer on 2800 end users.

The company is a common health insurence in Holland.

Edwin