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.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

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.
Answered 06/15/2005 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
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!
Answered 06/15/2005 by: norexx
Orange Belt

Please log in to comment
0
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.
Answered 06/16/2005 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
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.
Answered 06/16/2005 by: Francoisracine
Third Degree Blue Belt

Please log in to comment
0
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! [:)]
Answered 06/16/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
At my shop we have about 2000 user and 1 1/2 packager
Answered 06/16/2005 by: linstead
Blue Belt

Please log in to comment
0
Linstead,

Do you have a midget packager in your shop, or is the packager really, really big? [:D]
Answered 06/16/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
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 :( )
Answered 06/20/2005 by: dbowe
Orange Belt

Please log in to comment
0
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.
Answered 06/21/2005 by: Bladerun
Green Belt

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

M
Answered 06/22/2005 by: MSI_repackager
Orange Belt

Please log in to comment
0
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...
Answered 06/23/2005 by: norexx
Orange Belt

Please log in to comment
0
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
Answered 06/24/2005 by: MSIMaker
Second Degree Black Belt

Please log in to comment
0
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...
Answered 06/24/2005 by: Francoisracine
Third Degree Blue Belt

Please log in to comment
0
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
Answered 07/04/2005 by: Siebrasse
Senior Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity