Desktop engineering, again

Let's look at the definition I proposed for desktop engineering a little more closely:

Desktop engineering is the set of activities that strive to create a broadly used baseline desktop environment that is consistent and verified.

Broadly used baseline - Though there are some situations where you want to engineer for special cases or "one-offs," in general, it isn't cost effective to engineer something that you are only going to do one time. Also, since one of the goals is consistency, you want to focus on what is similar across the enterprise, not on what is different amongst pockets of users. Therefore, the primary focus of desktop engineering is to engineer for the entire enterprise, or a significant portion of it. If you believe in (or, perhaps, misuse) the 80-20 rule, then you want to engineer the environment that 80% of the people use all the time, and leave as one-offs the other 20%.

Different companies use different measures of when and when not to engineer a desktop component. Some might say that they will engineer a component if x number of users use it. Others will do a cost/benefit analysis, balancing how much time an engineered environment saves in terms of user and support technician time versus the money it requires to create that environment.

I said above that "in general" that you wanted to engineer the common components. When might you want to engineer the unique items? Desktop engineering makes sense for unique items when the benefit is great enough, such as avoiding a desktop visit by a technician or allowing for greater security. For example, if your users run with limited user rights so that they cannot install applications, and you have a system that allows these applications to be installed remotely (like SMS), you will need to engineer every application that users need installed if you never want to have technicians visit a desktop to install an application. Some companies will do this, even if only one user uses the application.