What is the average ratio of repackaging engineers to end users (or applications) at most companies?

Just wondering if anyone out there has any data on what is the average ratio of repackaging engineers to end users (or applications) at most companies?

Right now my group (5 FT MSI repackagers/testers) is trying to justify the cost of adding more staff to management. We have 100,000+ end user, and 600+ currently repackaged MSI applications, with about 10-12 new requests coming in each week. Many of these are extremely complicated client-server multi-module "home grown" apps that require an above-average amount of time & tweaking in order to deploy/work properly. With a 20,000:1 engineer:user ratio, needless to say we're getting hammered.

Any stats anyone could contribute (anecdotal or otherwise) would he hugely helpful in selling the need for more engineers to manangement.

Comments

Answers

0

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.

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].

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! [:)]

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.

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:

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 ;-).

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...