Packaging Process

Managing Packaging Projects – Packaging

With standards in place, the process confirmed and discovery info beginning to come through, it’s time to start packaging. As it is just a conveyor belt process just grab a couple of cheap resources and lets get cracking…

Managing Packaging Projects – Packaging

Ok, so I’m just trying to get your attention, but you wouldn’t believe how many people I have heard use the above sentence.  It does make the point though that the art of packaging is a very misunderstood process; indeed it is a repetitive task that’s seems fundamentally easy. You take a clean machine, install some software, take a snapshot and capture the difference between the clean machine and the install. Simple.

What this process doesn’t take into account is the complexity of configuration, the dependency analysis and the understanding from a coding level as to how applications are put together. When an application throws an exception on your new operating system, it is necessary to work out why, by capturing the API calls made by the executable using tools such as Depends, RegMon or FileMon.

This type of knowledge takes years to assimilate and understand and that is why most good packagers will also be pretty proficient coders, web developers, and SQL Server admins. They will understand how applications interact on a code, operating system, network, database and protocol level.

This sort of knowledge comes at a cost; not only from a financial perspective but from a management perspective too. A good packager will be able to work autonomously and rattle through the newly discovered applications while ensuring they are following the standards and quality criteria. You would think that this would be great news for the project. Unfortunately you have to balance this potential speed with the realisation that this is a highly skilled yet fundamentally boring process. Some applications provide challenges while others won't.

The challenge then becomes one of keeping your best packagers focussed while not letting them get bored: either by getting them to mentor your weaker packagers or allowing them to use their skills to benefit other sides of the project. This is going to sound counter intuitive, but some of your better packagers will want to help out with some of the more technical challenges to the project.

You may need to build a web based request portal, work out a technical installation process for your operating system or even help the developers to understand how to integrate their applications with other systems. Giving your packagers additional smaller challenges are all good ways of keeping the packaging process moving along while keeping interest high. As long as everyone is completing their quota, you can use the spare cycles to keep moral high and work out some of your more technical issues.

I guess one of the questions you may ask is: “Why can’t I just use cheaper resources and push harder?” and that’s a good point. However it’s always going to cost you in the long run. From an outsource perspective it's an easy call. Many of these companies will just pile up the packagers and get the process churning through the applications like the conveyor belt I mentioned at the start of the article. The challenge here is to understand your future costs.

Here is an example of what I am talking about: an in house packager will spend a number of days creating a multi configuration package to suit many different departments. An outsourced packaging company will undoubtedly be charging on a per package basis and will want their resources to get through the process as quickly as possible and therefore produce multiple packages for each configuration. Either way is not bad practice it’s just a case of balancing outsourced companies business drivers with the client companies business drivers.

Also, cheaper resources will not have the experience that you may be looking for to package some of your more complex applications. This can leave you with the choice of having to recruit a technical trouble-shooter to assist the packagers when they get into difficulties.

Packaging isn’t just a technical process however; it is also a chance to capture knowledge about your application portfolio in a way that may help resources further along in the migration process. You will therefore want you packagers to be able to annotate the application knowledge base as they go along. This is often valuable information captured outside of the formal discovery documents such as pointers on what to expect on first launch or who is a good person to talk to if there is an issue etc.

So where does AppTracker fit in to all of this. AppTracker provides the ability to annotate the knowledge base whichever process you are working in. Adding notes, further discovery information, document attachments, and screenshots are all possible using AppTracker’s easy to use interface. In addition, a historical record of all changes to the knowledge base is kept to ensure data integrity.

I’ve also talked about how talented yet difficult to manage most good packagers are. An important function of AppTracker is it's ability to report extensively on process, user, workflow and discovery information right out of the box. It's no good thinking you have a great team, and have collected loads of valuable date if you can’t report on it.

This hasn’t been the longest post but there isn’t much to say about packaging from a business perspective. I’ll finish here and summarise:

  • Packaging can be a complex yet repetitive process
  • Use highly skilled packagers where possible to save costs in the long run
  • Chose a strong team leader to keep both moral and throughput high
  • Balance your team and allocate applications where appropriate
  • Understand that highly skilled packagers can add value outside of the project to tackle challenging issues when they arise
  • Make sure you can report on how well your team is doing
  • Ensure that all of your valuable data is accessible and reportable

Managing Packaging Projects – Discovery

Managing Packaging Projects – Discovery

This is the part of the project where you either begin to smash your budget or settle down to some serious work. By this time you should have established your packaging standards, developed your core build, understood your test and quality criteria and have established a cast iron upgrade policy. Please tell me you have….. 

While the audit phase will define your project and give you the size of challenge you have ahead, the discovery phase will define your approach to the whole project. I’ll go through the points I made above first and then move on to the meat of the discovery process.

Packaging Standards

Your packaging standards are an incredibly important part of the project. They will define how you interface with the other technologies in your programme. I’m assuming that with this packaging project will come a new desktop, software delivery mechanism, some form of testing etc. With any project that is over 200 applications will come the requirement to automate some of these steps: with automation comes the need for consistency and that means standards.

Core build

Your core build defines the platform on which you will install all of your new application packages. It will consist of an operating system, drivers, key security products and a number of productivity applications such as Microsoft Office. It’s important to lock down the core build early on and establish change control as this creates the baseline upon which all your applications will be tested.

Testing and quality criteria

I’ll cover testing and quality criteria at a later date as they create their own set of processes and management challenges but it’s enough here to say that testing and quality are the two components that directly impact your relationship with external suppliers and business users. If you get this wrong you will be punished both financially and reputationaly throughout the project.

Upgrade policy

You might think the other points can create a headache but this is where your financial director could start to squeak. Lets take a couple of examples to understand the challenge:

1) You have 500 users who require some sort of file compression utility. During the audit you found that you have half the users with version 7 and the rest with version 9. You’ve already calculated that the packaging cost for each application is going to be around £1000. You also find out that the upgrade cost to move the users from version 7 to 9 is £2 per user. It’s a no brainer. To keep both versions is going to cost you £2000 in packaging costs. To upgrade and package just one application is going to cost you £1500. Easy

2) You have some sort of widget manufacturing design software. Used by 200 people in the business it is a critical piece of software.  Recently one of the business units upgraded 50 users to version 2 at a cost of £50k for additional functionality. The other users didn’t need that extra functionality. During discovery you find that both applications work perfectly well on the new operating system. The manufacturer only supports version 2 of course and your compatibility software points out a couple of minor issues with the previous version.

You can see where the second example is going. If your upgrade policy contains any of the following:

  • All users must use the same version
  • All errors with the compatibility will be dealt with through upgrade
  • If the manufacturer says upgrade then we have to for support reasons

Then you’re committed to spending a lot of money. You have to be pragmatic about this and you have to look at the external costs whenever you come up against these questions. If you’re not careful your upgrade policy can turn your £1 million project into a £10 million nightmare.

On to Discovery

Discovery is the process by which you learn how an application works, how it’s connected to the outside world and how it’s configured within your organisation. You will often have to search for the relevant person within the business who installed the application five or ten years ago. It is very important at this stage to capture your knowledge in a format that can be mined for information at a later date.

For example you may wish to keep a track of all applications that act as Add-Ins to Microsoft Excel, or all applications which cannot be virtualized. You may wish to detail which servers the application connects to so that you can build a dependency tree at a later date.

The knowledge and information that you collect at this stage is going to be crucial to the outcome of the project. The accessibility and security of this data is also of paramount importance. It’s no good having fantastic discovery documentation if no one knows where it is. You will also wish to collect notes as you carry along through the processes that will be pertinent to other people who come across the application. It’s at this point you may start to realise that an Excel spreadsheet just won’t cut it for gathering information. You will also start to appreciate that having a folder structure and collection of documents for each application is just going to obfuscate the valuable knowledge that you have collected.


With AppTracker, we have created the ability to dynamically build your own discovery knowledge base through the use of questionnaires. These forms can be used to create very powerful reports across your whole application portfolio. Your installation documents can also be stored as attachments for easy access by your packaging, testing and deployment teams.

From a workflow perspective, it is important to understand that the discovery phase will overlap with the packaging and testing processes. Discovery will not only act as a driver to the rest of the processes, it will also be required to capture change during the natural life of the project.  Applications will always require updates throughout the project in a similar way to BAU packaging. There will also be cases where applications fail UAT due to configuration issues that will need to be rediscovered.  There is nothing more frustrating than having a stack of rejected applications waiting for further configuration details while your packaging team struggle to churn through the current list of applications they have.

Application compatibility provides a means of rapidly checking your application estate for issues likely to affect your migration project. Be warned though, this is a danger point for your upgrade policy and you have to be pragmatic about what you are trying to achieve.  There is always a battle here between technology led purists who want to make sure the new environment is pristine, and the business led managers who want to keep the costs as low as possible.  It is therefore necessary to define a compatibility workflow that is right for your company and understand which issues are acceptable from a risk and impact perspective.

The last point I want to make about discovery is that it is a process that has a direct interface with your business. It is therefore important to choose the right people: they must be technical enough to understand the software dependencies, intelligent enough to make decisions based on risk and cost, and friendly enough not to frighten or annoy the business users. This is important because many of the business users who are contacted during the discovery phase are also going to be the people you will ask to test the applications during UAT.

This has been quite a long post, but this process is incredibly important to the outcome of the project as a whole. So, finally, to summarise: 

  • Make sure all of your standards and policies are in place
  • Make sure you have defined your quality criteria
  • Have an upgrade policy that matches what you are trying to achieve
  • Make sure you overlap your resources
  • Do not let your toolset drive your project, rather use it to make decisive choices.
  • Chose the right people for the job
  • Make sure the knowledge you have collected is centralized, accessible and secure

I hope you find these posts useful. I have put them together based upon the knowledge I have gathered over the years carrying out application migration projects. Please feel free to leave comments or ask questions.

Managing Packaging Projects – Audit & Rationalisation

Managing Packaging Projects – Audit & Rationalisation


Many desktop transformation projects start off with a Project Manager a Desktop Engineer and the sudden revelation that there are over “3000 Applications” to package in just under 6 months otherwise the World's going to end.  This of course isn’t the case but it often takes a while to understand this.  The large number of applications often comes from a misunderstood report produced by desktop configuration management software such as Microsoft’s SCCM. 

Unfortunately this sort of analysis often leads to panic at the start of a project: the project manager realizes that they have no chance in completing what they have set out to do. It’s only at the end of the project that they learn that there were only 700 applications and the report they were using at the start of the project was actually a list of all the executable files installed on every computer.

This is probably my most repeated phrase about packaging projects: “Do your Audit at the start of the project and not at the end when you think you are ready to migrate your users.”

I know it seems a ridiculous thing to say but it happens every time.  The programme manager will come out with all sorts of excuses as to why its too early to do an audit when: they are nowhere near ready to migrate the users; the business won't want to be disturbed, it costs too much, everybody’s requirements will have changed by the time we are ready etc...


To take each application through the full transformation process will cost the project around £1000. That seems like a lot of money so lets do a quick analysis: 

To discover how the application is configured, document and test on the new operating system will take on average of one day. Another day to package, document and ensure it works. Then on to QA, User Acceptance Testing, any remediation, and finally, release to live will take the best part of another day. At £350 per day for contractors that full process adds up to £1050. It might seem a little loose but once you take into account the running around and scheduling users and techies it's about right. 

If you think it’s going to be cheaper by outsourcing to an offshore company then think again. You still have to manage the process interfaces and managing the quality becomes a real cat and mouse game.

So, back to audit, you think you have 3000 applications and you have just budgeted £3m for effort. You have also just worked out that at three days per app it’s going to take you 9000 days effort (plus time for holidays - they do happen!) If you cram that into six months then you’re talking about a team of at least 75 people: and that’s starting at day one.

Can you start to see the problem here? We’ve just geared our organisation up to complete a packaging project in six months at a burn rate of at least £26k per day (75*£350) and have no idea where the first application is coming from, who really uses it and whether it is suitable for your new environment.

Of course we’ll still look like heroes because, as I said earlier there will only really be about 700 applications to do. We’ll come in on time, within budget and will have only wasted £2.3M on resources we never really needed ...

It takes time to do an audit, it takes resource and it looks like you're not achieving much: but in the long run it’s going to save you money - lots of money. 


At AppTracker we have thought about every step of the packaging process so that you can define, manage and deliver your application transformation projects in the most cost effective way.

An Audit should be broken down into manageable units. If you think you're going to be migrating users based on Business Area, Office, Building, or Country then drive your audit in the same way. At AppTracker we call these BluePrints as they help define the plans for migration. 

Once you have defined your BluePrints you can import your audit results into AppTracker and manage the application rationalization process. Once the BluePrint owner is happy that they have all the applications they need you can get sign off and move them into the packaging process.

In this way you have a signed off set of deliverables for a specific migration unit. Your costs are being managed and your time-scales can be set.