In many cases we don’t seem to realize the benefit of recognizing a project’s genre as early as possible. And what happens? Methodologies and processes - perfect or imperfect – are forged by yet another set of guys in the organization and deployed in execution. This is both an avoidable waste and a serious risk.
Consider migration projects: a version upgrade of MS Exchange, legacy Cobol to Open Source, VB or VC++ to (Dot)Net, ASP to ASP(Dot)Net, etc. Some are readily recognizable as such at first glance and some show themselves up as migration projects only when looked under the hood. Some are migration projects in toto and some, only in parts. With so many flavors and variants, clubbing them all under the genre of migration projects seems to be an exercise in intellectual abstraction without any practical pay-off.
Not so soon. If these non-rewrite migrations are examined more closely, usually they do exhibit certain common characteristics:
- Usually no time is made available to fully understand the source system to be migrated. A large amount of code needs to be migrated in a short span of time. The corollary is: such a project is largely methodology/process driven. Recall the spate of Y2K projects.
- The processes are usually designed around usage of some tools. But tools, in most cases, do not carry out a 100% migration. And some manual efforts, often representing a good part of the overall estimates, are required to finish the job completely.
- Estimates of time and effort are made based on a sample and are accurate to the extent the sample is representative of the whole.
- It is possible to establish some kind of a trade-off between the effort estimate and the quality of migration. Defects in migration are a given as with any software related activity.
- A migration project is amenable to an assembly-line like staffing. One team may be carrying out impact analysis and another applying the transformation of source to target.
- Since the source code is not comprehended to any great extent, heavy involvement of users is required to test.
- A pilot may be required to validate the methodology, tools and estimates and to reassure the user that all is well.
- Enhancements and bug fixes are deferred until migration is completed and validated.
- Migrating legacy data is a non-trivial task and needs to be thought thru.
A methodology woven around these characteristics takes much of the thinking out of planning and executing such projects. It can otherwise be quite daunting and risky without this canned wisdom. The software/tool vendors usually do a good job of putting together a step-by-step approach. Rolling out a portal product or an e-commerce site are examples.
It is a good practice to maintain a catalog of processes for various stereotyped projects. For a given project, the set of processes appropriate for the genre is pulled out from the catalog and customized to fit the boundaries of the project.
When the sheer variety defies useful abstraction, sub-typing the genre into narrower classes could be attempted.
Tags: Migration, Project, Project Genre
July 1, 2008 at 8:52 pm |
This is a unique and a very well-written article, I am interested in republishing this article on PM Hut. In case you’re OK with this, then please email me back or use the Contact Us form on the PM Hut site.