Transformation projects

An organization that maintains software can run several types of projects. Some are simple, others are complex. One of the most complex projects can be what I call "transformation projects", which change the nature of the software.

Examples of these transformation projects are:

• Upgrading to a new version of the compiler or IDE
• Changing from one database to another
• Expanding to another computing platform
• Converting from one language to another
• Moving from one computing architecture to another

All transformation projects are not equal. Upgrading a compiler (say Visual Studio 2010 to Visual Studio 2012) is a minor affair. The existing code still compiles. The existing design still works.

Compare that simple project to changing the system's database (for example, switching from MySQL to MariaDB, or possibly Microsoft SQL Server to Oracle). While SQL databases are mostly compatible, they are not exactly compatible. They use different languages for stored procedures. They have different techniques for the optimization of queries.

Transformation projects frequently add no new business features to the software. Consequently, many organizations perform them rarely, sometimes only when necessary. Such a strategy may be viewed as responsible, since by not spending time on upgrades you can focus your effort on features which bring measurable benefit to the business.

But such a strategy has a cost: you have no practice at these transformation projects, and consequently often underestimate the time and risks of such projects. Frequent (or regular) transformation projects gives you experience, which you can use to estimate the time and risk of future similar projects.

I should say "accurately estimate", since you can estimate any project, with or without experience. But experience gives us better estimates. For example, I (and I suspect many people) can accurately estimate the time needed to commute home from the office. They actually do commute home, so they have experience and can (reasonable) assume that future commutes home will take the same amount of time.

An estimate without the corresponding experience is subject to greater variance. As a counter-example to the "time to commute home" example, can you estimate the time it would take to walk to Argentina? (If walking is too long, you may substitute driving.) Such a project contains unknowns: tasks for which we have little or no experience. (In this example those would include crossing national borders, obtaining licenses to drive, and paying for gasoline in foreign countries.)

When an organization avoids transformation tasks (for whatever reason), it foregoes the experience of those projects. When it decides to perform one of those projects (because eventually you will need to perform at least one of them) it has no experience to use in the formulation of the plan. The project schedule may have wildly inaccurate estimates, or may omit important tasks.

The transition from web app to cloud app is such a transformation project. So is the transition from a desktop app to a web app, or a cloud app. If you are working on such a project and find that the project schedule is daunting, difficult to prepare, or just not working for you, look back on your experience with similar projects. If you have none (or very little), then perhaps experience with similar, smaller transformation projects can help.