In-Depth

Pack ‘Em Up, Move ‘Em Out

Migrating applications is far from easy—that’s why choosing the right tool is imperative.

• By Danielle Ruest and Nelson Ruest
• 07/01/2004

T&T Corporation's network migration was going full blast, or so thought Donald P. Apscott, an MCSE who just so happens to be in charge of the move from Windows NT to Windows Server 2003. Don has already put together a team and delegated some of the migration activities. Because he is an MCSE (on NT4—he hasn't upgraded his skills yet to 2000 or 2003), he took control of the Active Directory portion of the migration, but that still leaves three other migration areas to be taken care of: member server migration, application server migration and, of course, PC migration.

Being the smart fellow that he is, Don demanded that best practices be used everywhere. That's why he decided that all installations, both servers and workstations, would be clean installations—no upgrades anywhere. And since all machines were to be reinstalled, the project team would use a system construction model to prepare the machine builds and manage machines once they were deployed. After a bit of research, Don found the PASS Model or Point of Access to Secure Services (see Figure 1).

Figure 1. The PASS System Construction Model. The PASS Model provides a logical structure for the construction of corporate computer systems. It applies to both servers and workstations. In the case of the latter, role-based configurations focus on user roles, whereas with servers, they focus on machine roles.

This model is based on the construction of a computer system that responds to corporate needs in three ways:

• The PASS system "kernel" is designed to meet the needs of the average corporate user. It contains all of the software components required to perform basic office automation and collaboration tasks. This includes all software for which T&T has a corporate license, all software that is royalty free and required by all personnel, as well as the basic operating system. The system kernel is divided into a series of layers similar to the OSI Networking Model. In fact like the OSI Model, it uses seven layers to provide core corporate services. Because its functionalities are required by all personnel or all servers, this kernel is installed on all computer systems.
• Role-based applications and software are added on top of the kernel to meet the requirements of special Information Technology (IT) roles everyone plays within the organization. Applications are in-house programs that meet mission-critical or mission-support functions. Software is identified as commercial software products that are not required by all personnel, but only for specific roles or tasks.
• Finally, an ad-hoc layer responds to highly specialized IT requirements that are often expressed on an individual basis. This ad-hoc layer can contain either software or applications.

Don likes PASS. Constructing systems based on PASS greatly reduces the system management burden by reducing the number of programs that must coexist on any system. That's because a good portion of systems, sometimes up to 50 percent or more, only require the system kernel. This makes these systems the easiest to manage. In addition, by grouping non-kernel programs into role-based configurations, IT can reduce the complexity of each system; role-based configurations include every program that is required by every member of the IT role grouping. For example, Intranet Editors would require a web editing tool, a graphics tool, a Web-oriented animation tool, and other Web-specific utilities.

The same goes for other IT roles. The tools contained in each role grouping can be packaged separately, but should be delivered as a single unit on all systems belonging to the IT role. These configurations often include no more than 10 to 30 individual programs depending on the role. To avoid all possibility of software conflicts, the tool groupings in each role only need to be verified with each other and against the contents of the system kernel. There is no requirement to verify or test the cohabitation of programs contained in different configurations because they are not likely to coexist on the same system.

Finally, categorizing programs into an ad-hoc layer reduces system management efforts even further because these tools are only required by very few users in the organization. They should still be packaged properly to enable centralized distribution and automated installation, but once again, they only require testing against both the kernel and the role-based configurations they will coexist with. Because of their ad hoc nature, they may coexist with several configurations. For example, a Web reporting utility may be required by IT personnel as well as managers in different parts of the organization, making it coexist with several role-based configurations.

Though using a system construction model simplifies system management, it does presuppose that all programs will be and should be prepackaged according to corporate standards. Don thought that was self-evident. But it wasn't so apparent to his system construction team. It turns out they just realized that they needed a professional software packaging tool to prepare T&T's more than 200 programs for deployment into the new infrastructure. They thought they could use a variety of different methods for software installation automation, but they soon discovered that doing it this way was too time consuming and produced unreliable results.

Now they've decided that they want to package everything they can into Windows Installer-compatible or MSI-based installations. Don was furious. This decision should have been made at the very beginning of the project. Now, it will cause delays since they have to undergo a new software evaluation process. Once again, it will fall to him to determine which tool to use.

All is not lost though. The system preparation team has already categorized the type of packages they will need to create and Don was able to find a structured method for testing software installations and preparing packages (see Figure 2).

Figure 2. The Software Packaging Process. Packaging software involves five major steps. It begins with an authorized request for a software product, followed by the initial discovery or analysis of the software's installation process and production of the initial package. This is followed by product testing and quality assurance. The latter is essential to ensure the stability of the systems the package will reside on. In the last step, release management, the software package is released for distribution by the organization's software distribution system. (Click image to view larger version.)

It turns out that there is a lot of help on the Internet on this topic. One site in particular, AppDeploy.com, was very helpful. It even contains a software package Knowledge Base that lists information on more than 200 packages (see "Additional Information"). T&T categorized its software assets into four groups:

• Native Windows Installer software — This software includes any product that includes an original MSI or bears the Designed for Windows logo. Part of the requirement for the logo program is integration with the Windows Installer service. The installation of these products can be transformed to custom configurations for T&T's network. Don's migration budget includes the upgrade of several products in use in his network, especially those found in his system kernel. Not all products can be upgraded though because of budget constraints.
• MSI-integrated corporate applications — New or upgraded versions of corporate applications should be integrated with and designed to work with the Windows Installer service. T&T's internal developers must learn to work with this format.
• Repackaged commercial software — All commercial software products that are not upgraded will be repackaged to integrate their installation with Windows Installer. Some 99% of the software products that will not be upgraded can be repackaged to take advantage of Windows Installer. Only products such as device drivers, programs which install device drivers or programs which make low-level changes to the operating system will resist Windows Installer integration.
• Repackaged corporate applications — Corporate applications that do not require recoding, upgrades or cannot be reprogrammed will also be repackaged to be integrated with Windows Installer. This will include some corporate, regional, and departmental applications.

Categorizing all of their programs took time, but it was essential to estimate packaging timelines. It also helped update the corporate inventory database which is an important part of any migration project. Now all that's left is to select the right packaging tool. Don has it down to four contenders: AdminStudio Professional from InstallShield, WinINSTALL MSI Packager Professional from OnDemand Software, Package Studio Professional from Wise Solutions and Prism Pack from New Boundary. He also found a neat little tool that he wants to include in the evaluation. It is called PackageCleaner and comes from iTripoli, Inc.

Don selected these tools because they only provide packaging services. All the other tools he found on the Internet also include a software distribution function, but since his network already has this functionality, he didn't want to pay more for something he already has.

To test these tools, Don used software products from two categories: native Windows Installer software and repackaged commercial software. For the first, Don plans to modify the installation of Microsoft Office 2003 since he knows his users are anxious to get their hands on the new Outlook. For the other, he is going to use an older version of WinZip since this is one application his project isn't paying to upgrade. In addition, he knows that Microsoft is preparing a new version of Windows Installer, version 3.0, but he doesn't think it will be released until the summer so for now he's going to continue working with version 2.0.

InstallShield AdminStudio Professional
The installation of AdminStudio is very straightforward. It runs as a single MSI that installs most of the tools in the AdminStudio suite by default. It also creates a share point from which packages can be released when ready and package databases can be shared between multiple packagers. One of the most impressive features of this tool is the interface (see Figure 3).

Figure 3. Working with AdminStudio Professional. AdminStudio provides a complete set of tools in support of the packaging process. It initially launches in the Quick Start Guide which serves as a great introduction to the topic for newcomers to packaging. (Click image to view larger version.)

AdminStudio starts in the Quick Start Guide. This guide asks seven basic questions to the software packager. To view the answer to the question, simply move the mouse over it. Click it to view a short presentation of the tool. These presentations lead the packager to the right tool for the job at hand. But while this interface is great for the first-time packager, it is not the interface you would use on an ongoing basis.

That's because the interface also includes two tabs at the bottom left of the screen; these lead to both Projects and Workflows. These two tabs provide a more sophisticated interface than the Quick Start Guide, but are also very powerful since the first lets you create packaging projects that provide a checklist of the activities to accomplish to complete the project, while the second provides a tool for the creation of new project workflows based on your own corporate standards. The advantage of these workflows is that it can help junior personnel create packages without a lot of sophisticated knowledge because the workflow leads them through the steps to use. That's why the Project tab is much more useful than the Quick Start Guide.
AdminStudio can store project information in one of three databases — Access, MSDE or SQL Server. T&T used SQL Server 2000 since it is more stable and more secure than any of the other two.

AdminStudio includes a host of tools in support of the packaging process. The Tuner lets you create custom transforms to modify the installation of Windows Installer-ready programs. One nice part of the Tuner is the ability to create Response Transforms. This means that you simply go through the installation of any MSI-based product and Tuner records your answers to create the required transform file. This certainly facilitates the process for newcomers to Windows Installer.

If your program is not in MSI format, you use the Repackager to capture legacy installations and store them in MSI format. It includes the InstallMonitor which watches the changes made to a system during installation as well as a before and after snapshot capability. According to InstallShield, InstallMonitor is the preferred legacy installation capture mode. That's why it seems odd that Repackager launches in snapshot mode by default.

Once your MSIs and MSTs are created, you can edit them with DevStudio, InstallShield's developer tool for the creation of MSIs. This is a full-featured version of the tool, so even developers can use AdminStudio.

For package quality assurance, AdminStudio sports several tools. QualityMonitor lets you test software once it is installed. It runs a battery of tests to ensure the installed program behaves as expected, even going as far as using the Windows RunAs command to let you test packages in user mode in restricted networks. This is great for packagers preparing installations for applications they are not familiar with.

In addition, ConflictSolver helps you resolve any conflicts between applications. Conflict detection is based on built-in Application Consistency Evaluator (ACE) rules, but packagers can also add their own. If you're really concerned about conflicts, the Application Isolation Wizard can automatically modify MSI installation parameters to ensure that applications are isolated; that is, they install their own versions of shared components without damaging or affecting any other application already on the target system. Using it in conjunction with ConflictSolver will ensure the highest levels of stability for all your packages.

AdminStudio includes other tools as well. The OS Snapshot Wizard is a great way to capture core operating system data and import it into the ConflictSolver database. This lets you validate packages against your core OS for potential conflicts. In Don's case, he was able to use this wizard to create a snapshot of his system kernel for PCs and verify applications against the collection of products included within it. Don was also able to create package groups in ConflictSolver to represent the IT roles he created for deployment.

Each role could include a copy of the OS snapshot along with the different packages found in the role. AdminStudio also includes integration with VMWare Workstation 4.0, one of the industry's leading virtual machine engines. Virtual machines are ideal for packaging since they are a lot easier to reset than physical machines. While AdminStudio only launches VMWare right now, it would be nice to actually run tests directly from the AdminStudio interface.

InstallShield is preparing a new add-on to AdminStudio. This add-on, called Patch Impact Manager, will integrate patches into the packaging process, supporting package upgrades and conflict detection. Though it sounds interesting, especially with the flurry of patches that must be managed today, Don didn't get a chance to either test it or find out its cost.

AdminStudio provides a very professional and comprehensive series of tools in support of the enterprise packaging process. Not all are necessarily easy to use, but the built-in help is comprehensive and supplemented by online assistance and a packaging knowledgebase. Don also discovered that InstallShield provides an Application Management System (AMS), and tested an online version of the tool. Coupled with AdminStudio, AMS 2.0 provides a more complete packaging environment supporting packager security roles as well as package requests and status reporting. It even integrates directly with Microsoft's Systems Management Server, letting packagers deploy the package without opening the SMS console. This is an asset since SMS is Don's deployment tool.

WinINSTALL MSI Packager Professional
Don looked at the WinINSTALL MSI Packager because he used it in a previous incarnation (a "light" version was included on the Windows 2000 Professional CD with an evaluation license for a 60-day trial). It was easy to use and especially install. You could package almost anything with it in a couple of straightforward steps. He enjoyed using this product and was looking forward to testing the latest version. But he soon discovered that, like all the other tools reviewed here, this version of WinINSTALL required a database.

Don first tried WinINSTALL 8.0. The setup actually installs an instance of the Microsoft SQL Desktop Engine (MDSE) with Service Pack 3 no less, but for some reason, it didn't create the database instance and tables required for WinINSTALL. To do so, he had to run a series of OSQL commands from the command line. Unfortunately, neither commands worked.

After a bit of research and communication with OnDemand Software, Don received a new version, 8.0.1. It worked a lot better. Database creation was run through a new add-on to the setup that runs you through the database creation process.

As far as he could tell, that was the only change in the software.
When he first launched the WinINSTALL console, Don had to connect to both the database and the WinINSTALL share. Fortunately, he took note of both values during the installation. In the other packages, these values are entered during setup and aren't required again.

Once the console was open, Don was most impressed with the Start Page which provides great information on packaging and packaging processes. But unlike the other tools, this Start Page did not provide specific information on how to create a package nor did it have links to the tools used to perform package creation. It turns out that packages are treated as lists in WinINSTALL which are stored in the Software Distribution node of the WinINSTALL tree pane in the top left corner of the WinINSTALL console screen. Once you click on the node, the packaging tools appear in the toolbar above the tree pane.

To create a package, you begin by creating a before snapshot, install the package and finish with an after snapshot-a process much like all the other tools. Once the package is created, it must be added to the Software Distribution—it's not added automatically—by first creating a list file, then importing the package into it. Once this is done, you can edit the package. WinINSTALL provides great editing tools, but the interface for editing is quite a bit more complex than the other tools. The tree pane lists all of the components that make up an MSI, but since it is so small, it is almost impossible to view the entire tree (see Figure 4).

Figure 4. Packaging with WinINSTALL. WinINSTALL packages must be managed from the software distribution node of the application. Once the node is selected, you have access to the packaging tools. (Click image to view larger version.)

In addition, the conflict management process was not as intuitive as with the other tools.

Don specifically wanted to test only products that focused only on packaging, but WinINSTALL is actually a complete software management system and the installation of the MSI Packager Professional is run with the same executable as the entire system, the only difference being the serial number used to install. Don was concerned that user error could lead to the installation of the wrong product.

Finally, for a manufacturer that is focused on the production of tools used to create sophisticated software packages, he found the installation process more complex than any of the other tools tested. To focus on a packaging only tool, Don decided to also take look at WinINSTALL LE 2003. The light edition is free from the OnDemand Web site. It quickly became obvious to Don that it doesn't nearly match the features found in the Professional editions of the other products he tested.

Wise Package Studio Professional
Wise Package Studio (WPS) includes comprehensive installation choices. In fact, after starting his first installation, Don decided to back up half-way through it to read the Quick Start Guide. That's because it told him he required Internet Information Services. On XP? Hmmm. In the end, he installed a complete copy of WPS on a server in his packaging lab. The server required SQL Server 2000 and Internet Information Services. That's because Don decided to use the Enterprise Management Server, as well as the Quality Assurance and the Application Gateway components in his evaluation. Since he is now working with Windows Server 2003, he used IIS 6.0. To his delight, he found that WPS was fully compatible with this operating system.

Once the server was installed and the Wise directories were shared, he was able to perform a client installation on his packaging workstation. This installs only the components required to link to the server and run Package Studio from a central location. This keeps the WPS footprint to a minimum on packaging machines.

Another nice aspect of Package Studio is that it starts directly in project mode. This may not be as fancy as the AdminStudio interface, but it does get you right down to business because the very first project is to perform an initial Workbench setup, customizing each of the tools it includes. You can also click on the Tools tab at the top of the screen. This lists all of the tools included in WPS. Each tool is grouped according to function and information on the tool is displayed in the details pane when the tool is selected (see Figure 5).

Figure 5. Wise Package Studio. Wise Package Studio offers a comprehensive set of tools for packaging. Each tool is grouped under the type of activity it supports. Details about the tool are displayed in the right pane once the tool is selected. (Click image to view larger version.)

But Don quickly returned to the Project tab to finish his first project. This is kind of like the chicken and the egg situation. The first thing you need to do is customize each tool, but to customize each tool, you must be familiar with the entire packaging process. Fortunately, Wise provides tool defaults to assist in the process. WPS supports several package targets including Windows, Palm, Pocket PC, Smartphone, server and Web applications. One nice aspect of a project in WPS is that each time a step is checked off as complete, the project automatically moves to the next step. This is a simple feature, but it was not available in AdminStudio.

There are some inconsistencies. For example, during the customization of SetupCapture, WPS' capture tool, it recommends the automatic building of the exclusion list, but this is not the feature that is selected. Odd. Like AdminStudio, WPS offers a tool for each flavor of packaging, from legacy captures to transform creations for native MSIs. It also offers the ability to convert packages from applications such as the SMS Installer. Don will have to check to see if any exist in his network since SMS is their deployment tool.

For transforms, WPS includes the InstallTailor which watches as you perform a simulated installation to capture settings into the MST file. Package Validation checks for the proper design of MSI packages including transforms (MST) and patches (MSP). Conflict management is based on standard operating environments which are very similar to Don's system kernel concept since they include every common application and configuration on PCs or servers. Conflicts can be detected through products groupings, supporting the IT role configurations Don devised. Applications can also be isolated to further enhance their stability.

The Quality Assurance (QA) component of WPS includes an interesting feature: Preflight Deployment. This feature creates an "empty" MSI package for delivery to target systems in the network. The package simulates a real deployment on all target systems and reports back to QA on the success or failure of the deployment. Don found this very valuable since it doesn't actually install anything on target machines, but immediately identifies machines where a deployment might not work. While this is not something he needs in his migration project since his systems will be built in a lab environment before delivery to users, Don can see this will be a useful post-migration feature.

A couple of other features Don liked were the direct integration with Terminal Services, letting him test packages for distribution to terminal servers. There is also a special Mobile Device Package Editor to work with the cabinet files required for these types of devices. While there is not integration with virtual machines, Don discovered that WPS worked very well with both VMWare and Microsoft's Virtual PC. Also, WPS includes a Virtual Capture capability. This creates an image of your operating system and tests packages against it. It's not virtual machine technology, but comes pretty close. In the release phase, WPS integrates directly with Active Directory, modifying Group Policy Objects to integrate the MSI for deployment.

Like AdminStudio when combined with AMS, the full WPS suite supports security roles, limiting packagers to only appropriate tools for the project at hand. It also manages packages as projects providing to do lists and letting managers or package requesters follow through on the status of their packaging project. This is a very complete packaging solution that fully supports all the processes in enterprise software packaging, especially when looking at the entire suite.

Prism Pack
Prism Pack has also been around for a while. It first came out as Picture Taker from Lanovation. Now New Boundary has renamed it Prism Pack and makes it available either with or without Prism Deploy. The installation was very simple, but to Don's amazement, it wasn't in Windows Installer format. Surprising that a company would sell a tool to create MSI packages, but wouldn't use it themselves.

Don tried Picture Taker before and he was pleased to see its familiar interface in Prism Pack. Of all the products tested, this tool was by far the easiest package creation tool to use. It works in a very straightforward manner. Launch the tool and it immediately displays the Prism Pack Package Expert (see Figure 6).

Figure 6. Packaging with Prism Pack. Prism Pack uses a wizard to support packaging. It is by far the easiest packaging tool to use and it provides most of the processes required for packaging. This is a good solution for packagers who don't want to spend a lot of time learning to package. (Click image to view larger version.)

Just follow the prompts to create your package. Once the package is created, you can edit it with a number of tools. You can also use the Conflict Checker Professional to verify conflicts, though this didn't seem as complete as the conflict checking capabilities of either AdminStudio or Package Studio.

Prism Pack also includes a series of partner products. Two of these are very impressive: Developer Studio and Install Tuner from InstallShield. You can use the former to edit MSIs directly while the latter is used to create transforms for your MSI packages. Don was impressed by these tools, but he wondered why New Boundary included them and why someone wouldn't just use AdminStudio since it includes both tools as well and has the same interface as both of them.

Prism Pack is a nice tool that is comparable to WinINSTALL LE in many ways though it includes more features than WinINSTALL's free product. In the end, Prism Pack just didn't include the features Don was looking for in a packaging tool.

PackageCleaner
PackageCleaner from iTripoli, Inc. PackageCleaner (PC) is a small utility built on the .NET Framework that examines completed packages to provide additional validation on package structure and contents. PC uses a comparison database to examine the contents of a package each time a package is selected through its interface. Like many new Microsoft products, PC must be activated on first use. iTripoli provides a customer ID number when you purchase PackageCleaner. This number is used for activation.

Once activated, PC appears and displays the PC Today page in the details pane. To clean a package, use File | Open, and locate the package. It is a good idea to create copies of the package before running through PackageCleaner because it will be modified during the cleaning (PC does create backup copies if you have set this option). Once opened, PC reads the package and starts identifying issues and problems it may contain. PC identifies three types of issues: critical, warning and informational. Once the package is completely open, you can click on the summary page in the main window to view the results (see Figure 7).

Figure 7. Cleaning a Package. By clicking on the Summary tab of the Main view, you can see the results of PackageCleaner's analysis of an MSI package. Three types of issues are identified: critical, warnings and informational. Each issue is explained in detail when you click on the item causing it. (Click image to view larger version.)

The bottom pane of the PC window displays either files or registry settings included in your package. Clicking on each one displays information about the item and explains the issues. Items in this bottom pane can be sorted by issue when you click on the top of the issue column. This lets you review items at issue quickly and easily.

To remove an item from your package, simply click the checkbox beside it. Once you're done, click on the Apply button at the bottom of the screen. Don't fear, though. PC does not actually remove an item from an MSI; it simply deactivates it so that it won't be installed. To remove the item, you can print the summary report and edit the package directly in your packaging tool. If you find an item shouldn't be removed during further testing, you simply re-open it in PC and uncheck the feature.

PC will remove extraneous components from packages, detect spyware, and provide specific recommendations for your package, all in one step. The database it feeds from is updated on a regular basis as new issues are discovered. One disappointing fact is that the updates are manual, though PC does provide you with a scheduled reminder for the updates.

In short, using PackageCleaner is like having a subject matter expert inside your firewall. Package content validation is perhaps one of the most complicated aspects of packaging; one that can only come with years of experience. PackageCleaner provides clear, concise explanations of why you should include or remove components in your package. This provides valuable support to even the most junior packager. Don thinks this is an absolute must for his team. In addition, PC works directly with all of the packaging tools reviewed here. Though it works with MSI files, it even supports the analysis of WSI files, Wise Package Studio's private packaging format.

Overall Evaluation
Serious packaging requires a dedicated team. Since T&T has over 200 products to package, Don needs to set up a permanent packaging environment and architecture. In fact, the packaging team should include a minimum number of players including subject matter experts, administrative staff and packagers. This team will interact with both users and product sponsors during the packaging process (see Figure 8).

Figure 8. Don's Packaging Communications Process. Packaging involves a series of different players in an organization. Each packaging project needs a project manager who deals with both users initiating package requests and product sponsors who authorize the request. Once the package request is authorized, it is sent to the packaging team leader who is also a subject matter expert. The team leader selects the proper template, based on the package type and assigns it to one of his packagers. Once the package is ready, it goes through a series of tests involving both quality assurance testers and product sponsors. The package is released once a final QA has been performed by the project manager. (Click image to view larger version.)

In addition to the original software categories T&T devised at first, there are several types of packages it will require. Don is already aware of the first two types: legacy conversion to MSI and native MSI, but his testing led him to understand that he'll also have to work with packages that are integrated with the .NET Framework, packages that require patching as service releases or service packs become available for them and packages that target mobile devices running either Pocket PC (now Windows Mobile) or Palm operating systems. He will also have to deal with conversions since his legacy network included packages in SMS Installer format. The tool he chooses must support all of these package types.

Don was a bit disappointed in the evaluations results. Despite the fact that they support the concept, no tool explicitly promotes the use of a logical system construction model, providing best practices for software packaging, distribution and overall management in a network. The closest to this was Package Studio with its standard operating environment capture tool.

In the end, it was hard for Don to decide. Both AdminStudio and Package Studio fully met his needs and requirements. Don also wanted to have his packaging team work with packages through the use of the packaging process he set up. Neither WinINSTALL nor Prism Pack supported the project concept. Though both AdminStudio and Package Studio support the addition of custom workflows in support of packaging projects, only Package Studio help make sure this was what his packagers would use. That's because AdminStudio opens the Quick Start Guide by default, letting packagers use the tools directly instead of forcing them to use the project process. This may be changed in a future release, but he needs his tool now. So he opted for the entire Wise WPS Suite, including the Enterprise Management Software, the Application Gateway and the Quality Assurance tools.

His final result will be an integrated request and fulfillment system for software provisioning in his network. This will take care of both his migration requirements and his ongoing software product management needs once the migration is over.

He also decided to acquire a few copies of PackageCleaner to support the quality assurance processes. This was an essential component to help control what goes on in the network. It is also very useful learning tool for packagers.

Software packaging is not easy; not easy at all. But with the right tool, the right processes and a proper design of project templates and workflows, T&T will be able to get it right.